Things we learned today: 1. USB is polling all the time 2. USB is insanely complex 3. There is always a fancier oscilloscope you don't have but really want
USB can push, but to my knowledge not for peripherals. Audio devices for example, can ask the host to push data IIRC. The complexity mostly due to the need of supporting a bunch of devices. These device have their own needs and data protocols. USB separates this as classes.
I know But There’s ☝️ Scope That Beats All And That’s Your First ☝️ I’m Still Waiting For GOD To Bless Me With ☝️ Until Then I Continue To Pray Someone Throws An Old One Out Because They Upgraded.
I'm honestly amazed with what you just did. You literally took a signal out from a cable and interpreted it yourself on paper. You just made this so understandable and real to me. Thank you
I love this approach! I do a similar thing when I run into cryptic programming algorithms that I don't understand: pull out a notebook, and go through the code line by line until something clicks. It can be very tedious, but when I'm working with something I find especially opaque, it takes away all the abstraction and make things feel more "real". The same sort of thing could be done by running the code through a debugger and watching a bunch of expressions... but there's something about manually writing things out on paper that makes information register better for me.
It's so easy to pass these devices off as mundane everyday items, but when you really get into it, they really are magic designed by hundreds and hundreds of smart people, current and past.
I'm a electronic engineer student. I confirm, yes. The most simple thing, like, 'Oh this thing only switch on and off the light' yeah, no. Maybe this cost hundred of hours in research
If you go the magic route, you can actually get quite a bit deeper. Q: How does that thing work? A: It's magic. You see, those things are filled with rocks, and those rocks have microscopic glyphs written upon them. Those glyphs interact with each other in complex ways to produce the effects you see.
@@johncochran8497 Paraphrasing a popular tweet from ages past: A computer is basically just a rock that we trapped lightning inside and tricked into thinking.
I am an electronics engineer and i cannot stress how much I admired you explaning this complicated topic as it was easy. If EEEN teachers are like you, all students could have succeeded easily.
I spent ~20 years developing learning technology for higher education and I have to say you have truly mastered it. I agree with everything said about how easily and quickly I was able to pick up details about USB - I love it. But your skill at breaking it down, basing your work on published references, (even though you likely already knew it) and walking use through the basics up to a more complex question was stunning. I've worked with maybe a hundred PHD / professional educators in engineering and many other fields. You far exceed anything I've ever seen. I'm fairly sure this is the 1st time I've ever liked and subscribed to any video/channel. Well done.
For PhD's it's not really surprising they don't excel at teaching, since they focus on research and academia, which unfortunately does not reward teaching skills at all.
Bluetooth keyboards and mice re-use the same HID protocol that runs on top of USB. In other words, you will see the same 8-byte packet for keypresses embedded inside of Bluetooth packets. I helped write the BT-HID specification.
@@vadzimdambrouski5211 At best, it can be as fast as 800Hz (1.25ms) but this is not typical. Bluetooth, at least Classic Bluetooth, had 1600 slots per second where the master polls each device in the piconet and each device responds. If there is only 1 active BT device in the piconet and if the packets are short enough to fit in 1 slot, then the polling can go as fast as 800Hz since the master and slave will alternate slots. However, most Bluetooth mice and keyboards use Sniff Mode to schedule how often to be polled (vaguely how the bInterval value affects USB's Interrupt pipe polling rate). On the upside, the Sniff Mode polling rate can dynamically change during a connection. For example, a mouse may ask for a very fast polling in Sniff Mode while it is moving. After a few seconds of no movement, it may ask for a slower polling rate (save power, allow more traffic for other devices). After a minute of no movement, the mouse may ask for an even slower polling rate. After several minutes of no movement, it may even disconnect from the Bluetooth piconet and go to sleep. If moved, the mouse will reconnect and go back to the fastest polling rate.
@@ChrisDreher if BT can reach 800Hz, why almost no device use them? BT peripherals always feel slow compared to USB cable, or even dedicated wireless. This is especially apparent when using high refresh rate display. On these display, it is easy to tell between BT or USB (wired/dedicated wireless).
@@UltimateAlgorithm This is partially answered above but it mostly comes down to 2 main factors. First, Bluetooth is a bus that Bluetooth devices share. The more devices you connect over Bluetooth, the less bandwidth that is available per each individual device. This is why some dedicated/proprietary wireless mice can be faster (depends on the wireless technology). Second, just like the difference shown for USB in the video, how responsive a mouse can be depends on how the manufacturer tuned the mouse's Sniff Mode polling rate. For example, Bluetooth gamer mouse will have a faster polling for better responsiveness than a business mouse or low-end mouse that will have a slower polling rate to extend the battery life. Third, and not mentioned above, is that USB has much more bandwidth than Bluetooth. So while USB has frames at 1000Hz, which is slightly better than 800Hz for Bluetooth (a best case), USB bandwidth allows for multiple devices to communicate in a single frame but Bluetooth can only have 1 device communicate in a single slot. This tends to push mice manufacturers to use a slower polling rate over Bluetooth so that other Bluetooth devices don't get starved for bandwidth. Part of the reason for "one device per slot" is that encryption and wirelessness is complex, difficult, and inherently noisy (problems that USB doesn't need to deal with as much).
@@ChrisDreher that make sense, shame that most gaming devices opt for proprietary connection instead. No one is actually making fast Bluetooth peripherals. Maybe it's bad marketing in game industry, where Bluetooth keyboard and mice synonymous with high latency. Although this doesn't happen with gamepads (PS, Xbox and Switch). All use Bluetooth yet have very low latency, on par with proprietary keyboard and mice.
That’s pretty much what engineering becomes at this level of complexity… you convincing yourself that things seem correct based on logic rather than always being 100% sure of everything. It’s often impractical to know things absolutely.
For USB hacking aficionados, worth mentioning that Wireshark (in addition to decoding network protocols) can also capture and analyze USB traffic! I used it to reverse engineer drivers for a silly USB-connected promotional pushbutton, as practice.
Currently doing exactly that to create a driver for an old scanner that isn't properly supported on Linux. I'm using Wireshark on Windows to figure out the communication protocol and then reimplement it under Linux. Such a pain in the ass. USB is so fucking complicated.
@@TheFool2cool Electronics and software is my hobby. I design and build PC boards for fun. Protocol reverse engineering and troubleshooting is a common part of electronic design. When you're trying to get your microcontroller talking to some other piece of hardware, this is what you have to do. I studied electronics in school, but my day job is in Information Technology.
In the gaming world, we call the issue where a number of keys can't be pressed at the same time, "ghosting." You were spot on with your analysis of why the smaller combination didn't work!
My Logitech Lightboard XL only supports 2 keys at a time which makes it impossible to perform speedrun jumps eg. Amazing how this silly looking keyboard can handle up to 6 keys!
The only thing I can possibly think of that could beat the visceral qualities of writing shit down on paper is MAYBE just doing that but in AR glasses.
yeah. also, never heard of actual data export in csv format or similar? Which can then be properly plotted on a computer? Dude seriously, cropping screenshots together in freakin PS? Okay then.. BUT: Awesome video and explanation!
@@RandomUser2401tbh combining screenshots is probably easier than taking a csv export and plotting it in excel or something. You could combine that screenshot in mspaint in like a couple minutes or probably less
@@misaalanshori if you don't plot for the first time, plotting a csv is a matter of minutes. Exporting all the different png screenshot takes longer than that. Hint: Serious plotting is not done in Excel, but python, Matlab, Octave etc
This completely demystifies USB for me. It's basically no different to communication 40 years ago, but at much higher data rates with additional necessary EM protection
In those 40 years, we went from serial for everything, to parallel when bandwidth was required (Laplink went so much better over parallel), and then with USB, back to serial for everything, only without giving up the speed. Then USB 3 sends us back to parallel (what do you think those extra 4 lines are for?). Time really is a flat circle.
Same thing with DSL: no different from 40+ years ago transmitting data over 2 wires of copper, just with advanced modulation techniques for much higher data rates.
I've been searching for a long time on how computers and their peripherals communicate on a very low, basically bit by bit level and this was an extremely well explained version of what I've been looking for. Thank you so much!
fun fact: the usb 3 lines on a Nintendo Switch dock aren’t properly shielded, so they can interfere with wifi/bt connectivity. some open source software for switch such as switchroot android have options to force usb2, which mitigates this.
Bens uncertainty therory. A datasheet when observed, can either have a lot of precision but lacks in clarity or lacks in precision with a high level of clarity.
@@sayamqazi I know it can be hard to find the time to watch something like this. But if I have the time these kind of videos glue me to the screen and 34 minutes passes like 34 seconds. Plus, there are tons of watered down videos out there that explain things in simple terms so that you get the idea, there are not enough videos that go into this much detail to really SHOW you how something works and demystify it completly.
I first learned low level programming (between assembly and lower level hex for debugging). Before starting my company and getting married, occupied a lot of time faking USB or serial devices with microcontrollers, just for learning purposes. USB data structure always fascinated me, because it'speed is only limited by the hardware speed. I mean, you can push it further and further, as long as there is time enough to receptor to acknowledge the signal ramps, there will be bit acknowledgement. I admire your work teaching some low level computing to the young, Ben. Thank you a lot.
One interesting thing to note between the USB and PS2 timings: Modifier keys and key releases take no extra bits on USB, but add extra bits on PS2. So in general USB is probably faster as long as it's full-speed and 1 ms polling rate, because you don't have the double/triple "packets" of PS2.
As far as i understand, is that PS/2 has a hardware interrupt in a proccessor, where a USB device has to wait untill it gets pulled and handled by software/processor. (but im not 100% sure)
@@TheNini666 the video does not really address what he said. USB keyboard can't tell independently if something changes. It can only answer when the host (computer) asks "what's up?". In USB host needs (AFAIK) keep generating those "what's up" requests, which is away from executing application code. PS/2 keyboard uses HW interrupt to tell the host when it has something to say. I guess this does not really matter anymore. Maybe it did 20 years ago.
@@fl4shi238 I'm fairly sure the polling is taken care of in hardware by the USB host controller, which then uses an interrupt to notify the CPU of data when something is actually received and not just NAK'd. So the CPU really doesn't have to bother with the low level polling. There are many different host controller implementations though, so some may be different.
@@Kitulous USB data transfer would be cool to see, as well as USB audio interfaces. Real time audio is one of the most complex things you can do over USB.
1:41 "it's got a lot of precision, but not a ton of clarity" you captured well what I find is complicating matters in technical topics frequently. Main message drowned out in a sea of details.
Yeah sometimes we're working on a microcontroller and we think initially there's no definitions, no basic overview of how it works. But after trudging through the details we find it's somewhere buried in paragraphs and sporadic. Sometimes it's just priority. Teach the person high level stuff overview then go into important details.
And to think you can spend a measly $200 (student price) for a Discovery 2 and a Sigroc free download and do almost the same thing. And it does dozens of protocols.
@@katemoon7476 BeagleBone Black running BeagleLogic + sigrok would be even cheaper, but it's only a logic analyzer (100 Msps 12 channels) for 2.5V-3.3V digital signal (unprotected 3.3V digital inputs) unless you add an external level shifter, and user-friendliness is probably sub-optimal (though I haven't played with it myself yet). Though on the plus side, whenever you have no need for logic analyzer it's still a beaglebone you can use for other things.
"So hopefully you found that interesting." Totally, it was amazing, so much detail, I love watching your videos. I've always been into simple electronics and computer programming, but they remained separate from each other, and watching your videos fills a void between the two and completes the picture. If only I could get hold of your kits without extortionate UK import duty.
Wow, this is just astounding. I'm currently back in school for an Electrical Engineering program, and I wasn't sure how well I'd be able to grasp certain comp sci subjects bc it's not my like, natural domain of understanding, but this channel makes so many of these topics so understandable but in a way that doesn't shy away from technically difficult info, and conveys it in such an intuitive way. absolutely A+ !
Reminds me of the days when I would lock myself in the room every day after returning from work, reading through the USB specs over and over again experimenting with a Cypress board, learning how to program the firmware so I could build my own keyboards, mice and joysticks. Now that I'm more than capable of doing that, I can't recall what exactly the physical frames look like. Thanks for making this video, helped refreshing my memory.
@@LuckyST Depends on what you're trying to achieve. If you're looking to get a general understanding, there's a PDF called USB in a Nutshell. If your goal is understanding the protocol enough to be able to build your own USB hardware. Jan Axelson wrote some very cool books. There are books from other authors, but they all boil down to the official USB specification. Get the 2.0, not earlier, not the 3.x either, I’d explain later. A couple of class specifications and tables with all the necessary values will be needed further down the track. It’s also recommended that you get the most familiar starter kit that you can find with a real USB core inside. FS (full speed) is good enough, HS would be an overkill and complicates things. Without picturing how you plan on altering the code for additional fancy features, try to run a few basic USB demo projects and get the kit running as intended, it should help you straighten up the dev environment and get you warmed up. Then comes the hardest part, intensive reading, you probably need hard copies of the most frequently referenced materials because all your fingers will come in handy as bookmarks to grab hold of / insert between the physical pages. Get the most comfortable mind map utility you have. I used a lot of blank sheets of paper back then, if you work more with digitized alternatives then that’d be better. You will run into a ton of terms and abbreviations that are both strange and related with each other. Before connecting the dots, you need to put them down somewhere like pins on a map. All the words read like nonsense to me in the beginning, it took me a lot of jumping around different paragraphs across different books before the Eureka moment dawned on me. And then I knew why the demo project was structured in a way to have all the strange structures organized in a handful of header files. All the descriptors and reports were just closely grouped there so it’s easy to customize them for new features. If you’re looking to understand USB on a deeper level and tweak around the signaling, probably working on FPGA cores in the future, the aforementioned route should familiarize you with the application layer. I never looked this deep TBH, but there are two places to look into if you’re determined. The USB core library of the starter kit, and some low speed keyboard / mouse projects using general purpose IO pins as D+ & D- signals to build the protocol from scratch. Existing projects are mostly the work of gurus and they are well structured for the sake of better maintainability or whatnot, which adds to the complexity to understand them. If I had the time, I would’ve built the code from the ground up, trying to experience every step it took the guru to figure out how each tiny bit of detail adds up. Making a bunch of ugly code work would’ve been my first milestone, finding ways to optimize them into something close to the existing demos would be the next. By then, I would have really understood why everything is the way it is. And I’d be able to advance into the FS signaling, later HS. Gen 3 and Gen 4 won’t be like total gibberish any more.
I'm blown away by how much this one half-hour video does to demystify USB. Seeing how one approaches the problem, measures what's actually happening, and interprets the results; videos of this quality are few and far between.
Actually I am not a hardware guy, but i stumbled across this video and i could not stop watching it till the end. Its that well made. Thank you for your effort Ben!
Taking notes so I can remember all the specifics the next time a recruiter or hiring manager asks me what happens when I type a URL into a web browser...
Yes. Maybe an Arduino Mini can be used here for reduce complexity. I use Arduino Micro for creating USB SNES and NES interfaces to PC or PS3. It's a real help to use it.
Thank you Ben for inspiring many of us to pursue this field. Your videos have, and will continue to be a source of motivation and interest for many generations of engineers.
My laptop's touchscreen uses a USB interface and appears as 2 devices when I listed the inputs and I never knew why, I thought it could be some Linux driver shenanigans. Maybe this have some relation. Very interesting
@@luizgfranca Linux ecosystem generally does not tend to go for shenanigans at least inside core components and system utilities. They just show all the ugly truths and dirty hacks as they are.
@@xugro no, they didn't. The "Doom on NES" runs on Raspberry Pi that's stuffed inside the NES cartridge, it runs doom and then inserts the image of the game in real time to the APU graphics memory... so it's not truly running on the 6502...
the BBC Micro is able to run a 3D wireframe based game (Elite) pretty decently while running at only 2MHz, Ben Eater can easily upgrade the Computer to run at 10MHz (by simply using the same clock for the CPU and VGA Circuit) so it could probably run a simplified version of the DOOM Engine... and with "simplified" i mean that to run at playable speeds you would likely need to lower the overall resolution and color depth to minimize the amount of data to be moved around or maybe just aim for Wolfenstein 3D since that's only raycasting with some 2D Sprites thrown in the mix which is much easier to do than a complete 3D renderer
Just because I didn't see it mentioned in any other comments, it's worth mentioning that there are low-cost USB protocol analyzers (e.g., a Beagle USB box) that can capture and visualize USB packets at a high level for and for reams and reams of data. From a software standpoint, debugging this on a scope is much too low-level to be practical. That being said, I've had to work with USB device and host controller drivers at several points during my career, and I've never seen the actual USB protocol so simply and beautifully explained as in this video. This is pure technical gold. Thank you.
You are amazing at explaining things like this. I've been trying to figure out the protocol by myself occasionally and could barely catch anything, but your videos are always very understandable and knowledgeable on the topic. Keep doing gods work Ben!
GREAT Video! I love seeing the low-level detail of commonly used protocols. We, as end users, don't realize the technology involved in even the most seemingly simple protocols! (even after having learnt all these encodings at uni, seeing them in practice is even nicer!) I really appreciated when you validated the CRC for us :)
OMG! This is amazing. I never thought it's done like that. I'm the head of a company, we design large ATS recruitment systems but watching such films gives me the greatest joy. It's simply brilliant how someone once designed it!
19:04 Interestingly, I think you can actually see where the line transitions control from the PC to the keyboard - If you look right after the red "end of packet" signal from the computer, you can see that the HIGH voltage of the line dips down a tiny bit. It also looks like the tops of the little "mountains" are a little bit more rounded when they come from the keyboard.
Yes, you can see this immediately when he lays out the printed copy at 5:24 or so. It's much easier to see on the D- line than D+, because D- is high when the keyboard takes over driving the line. This can actually be a lifesaver when debugging any multi-drop bus because it's so easy to get confused about who is driving at any given moment. In fact, a very useful debugging hack is to put a small value resistor either in series with the data line at one device or in series with that device's Vdd line (emphasis on the words "small" and "hack"). The idea is to lower the driver's Voh just enough to make the difference visible without compromising the data.
33:43 and since the user is equally likely to press a key at any point between polls the average latency is actually less than PS/2. Really great video. Imagine if he continued to up the complexity and did stuff like PCIe or DDR.
This makes me think the issue some feel with USB (Not me) might not be the latency itself but it’s variance. Instead of the predictable and repeatable latency of interrupt driven PS/2 they get subtle variations. In other words USB introduces jitter. I don’t know if a trained human can detect such minute differences, especially with all the other latencies involved in the modern gaming feedback loop.
@@rdoursenaud I'd be curious to see someone make an honest scientific (independent, randomized, double blind, ...) attempt to measure a performance difference that mattered in actual use. With old cheap USB keyboards in the early days of USB (possibly with bugs and just without any improvements a modern gaming keyboard would have)? Plausible that you could measure a real world difference, though I'm not sure a typical gamer would show it. Might require an elite level player to matter. But with a modern high quality well implemented gaming keyboard vs. a high quality PS/2? I'd be curious to see the experiment which would measure the practical difference. I could easily believe that there are badly implemented gaming keyboards out there, though. And I could believe that thinking you had a better keyboard might have a psychological difference regardless of which you thought was better and which one you actually had. Double blinding would be important. But ultimately it seems unlikely to me that you could measure differences that small. I'd expect them to be in the noise.
@@ratchet1freak Indeed there will almost certainly be at least some delay even for the PS/2 keyboard as I would imagine they probably implement some debouncing too. Human movement is pretty jittery at the micro scales which can be a problem right at the threshold of making or breaking the circuit. Adding a short delay before reporting the event helps prevent spurious input especially with the sort of soft switches you get in keyboards where there is no mechanical mechanism to ensure a hard transition from one state to the other.
27:31 The smaller combination that results in an error condition is called ghosting and that's from the current going in an unexpected way in the key matrix. More expensive mechanical keyboards often have a diode on each key to limit the direction the current can go, but membrane keyboards don't have a way to do that, so it just detects combinations of column and row signals that are ambiguous. I think some gaming-oriented membrane keyboards do some sort of clever wiring in the commonly used gaming keys zone (say wasd, qwer, maybe by wiring those keys as a single row/column rather than having those specific keys in a matrix arrangement) to make the signal unambiguous in that zone without using diodes. I've read that USB HID has a report protocol and boot protocol and the 6 keys + modifiers format is part of the boot protocol. Though I also read that fancier keyboards that support N-key rollover (NKRO) on USB often emulate multiple virtual USB keyboards (that presumably use the boot protocol) to send keycodes that are above the 6-key limit, rather than switching to the report protocol, and I have no idea why that is the case.
General-purpose keyboards usually have their matrix lanes built in a way that prevents ghosting when typing, at least in English. Cheaper gaming keyboards usually have different matrix lane layouts that prevent ghosting when holding down keys that are frequently used in gaming, such as WASD QE and the space bar. Higher end keyboards use diodes, higher lane count matrices, or individually addressed keys (for example fully-configurable RGB keyboards), and they either negotiate longer data packets, faster polling rates, or report themselves as multiple keyboards.
I watched this video for a project, I am literally goose bumped when you were hand decoding the usb code and the code just matched for the CRC and End of Packet code. Very very very impressed by what you did for this video, explored every curiosity I had about usb and ps/2. Amazing !
@@ELYESSS There are a few solutions, but the one I always take is simply to write less complicated interrupt handlers in straight assembly, and more complicated handlers using calls from assembly back into C code. I believe GCC has also started adding some sort of support for writing interrupts directly in C/C++, but I haven't looked at interrupt handlers in probably a year so don't take my word for that.
Sweet! Please show me the progress, maybe uploading videos on your channel about it. I've always wanted to watch and follow an OS being made, pretty sure other people are also searching for that, maybe even for guidance in their own projects
@@Perseagatuna Check out the OSDev Wiki page and Brokenthorn's OS Development Tutorials. There are lots of other links to follow out to others from there. You will find tons of resources on building an OS using those as a starting point!
This is one of the coolest things I have ever seen. Unless I'm just really bad at finding it it seems like their is almost no (or very little) content that goes in depth like this about physical layer and line encoding in such an accessible way.
Wow, another thing I've heard before and just didn't grasp, explained so perfectly that I _completely_ understand it. If I had teachers like you, the world would be a better place. Thanks for helping me to never stop learning. It really makes me feel good
@@PsychoBelka implementing that is a hell of a ride xD. I put a USB-C on one of my PCBs and hooking up the Controller chip with all its data and power pins to the chip and the battery was already slightly more complicated than I thought, imagine going from zero to that.
I am really amazed, I've never seen the comunication of the devices with such detail, this is awesome, and the fact that you could explain it so well to someone like me that doesn't have an idea of this from the begining is also awesome, thank you for doing this kind of stuff and keep feeding our curiosity
Such a good video. Just wow. Insanely high quality content, as usual. I really enjoyed seeing you decode the bits by hand, that was so cool. The fancy scope was a close second. Big thumbs up Ben 👍
That's because USB-A is 4 dimensional: it doesn't fit on the first try, when you turn it around it still doesn't fit, but on the next turn around it finally works ;)
I wasn't even looking for this subject and also don't have that much knowledge in electronics or protocols, but I can say now I know how USB works in the very basic level. Your video is insanely good, man.
Interesting. Looks like endpoint descriptors can specify their preferred polling interval but Linux at least allows you to override that for kid/mouse/joysticks using module parameters. So maybe even cheaper keyboards can outperform ps2.
@@FelipeBalbi considering that these devices are meant to be human input devices, that's absolutely more than enough. Even 16ms might seem a lot, but it's still a relatively low delay as it's the same length of a single frame on a 60fps stream. Considering thay the standard human delay reaction to input is in the order of hundreds of ms, 16ms could be noticeable, but 1ms is negligible to say the least
@@FelipeBalbi That is (mostly) true for Full Speed USB devices (i.e. 1000Hz is the max, ignoring some exceptions). However, on High Speed USB, the max polling rate is 8000Hz. If someone ever built a High Speed keyboard, it could theoretically be polled at 8000Hz. I don't know if any manufacturer ever built such a device, but it seems unlikely (haven't Google for those, though, so I could be wrong).
23:35 "... though you know they do make fancy oscilloscopes that will decode USB automatically. Unfortunately this isn't one of them." I thought that the video will end here, then... "BUT the people over Keysight were nice enough to lend me one that does!" :D
@@lifthras11r you can get a logic analyzer for much cheaper, since it isn't concerned with actually looking at the shape of the waveform, only the level changes! Then you can pull the data into software on the computer that decodes the data for you. It's neat!
I believe USB-C does still have a D+ and D- that could be setup to be different, but it would have to be designed intentionally to be obtuse like that. So unless your EE is a troll, it's is for all intents and purposes symmetrical.
@@coder0xff But there are crappy chineese USB-C to USB 2.0 adapters on the market that break the standard by only connecting D+/- wires to one of the 2 pairs. On some PCs they only work in 1 position and there is no way to know in which one until you try them and put some marking on the adapters yourself.
I just got into web development this year and UA-cam thought I'd like to watch you build a graphics card from scratch. UA-cam was right, but I also get a terrifying sense of existential dread when I think about my tenuous grasp on JS and also how much is going on "under the hood" that I'll never understand. You're a great instructor, but also this is all magic to me and I'm okay with that.
Another neat thing with USB keyboards is that on some you can actually increase the polling rate so you can get even less than the 1ms max delay that you showed at the end, at the expense of a bit more bandwidth having to be reserved on the bus, and the same goes for USB mice and their polling intervals
The thing is though, the game only processes user input during a certain phase of the game loop. That happens usually once per frame. So, if the game is running at less frame rate than the polling rate of the keyboard, there's no benefit to increasing the rate.
@@chyza2012 Yes, but there's rarely a useful situation where a game that need the uttermost I/O speed needs to know what key was pressed a second ago. So even if it's buffered, the bottleneck will still be the games processing rate rather than the polling rate of the keyboard.
"Understanding USB" for people who are too busy (or too intimidated?) to read the USB spec. Although I *used* many USB devices in the past (when I was still making living doing electronics) I never understood USB beyond (or below?) its applications level. Thank you for the enlightening tutorial.
I absolutely love the topics you cover in yo it videos. Other channels leave out so much in their tech explanations, but you take it to the next level and actually demonstrate how things work. Things like this, and your 8082 from scratch videos have taught me more about how computers work than any computer science course ever has. (not saying these videos are a replacement for a CS class, but if you’ve taken some, and feel that things aren’t clicking, Ben’s videos just may be that final physical piece of the puzzle you need to put it all together) Overall, phenomenal videos. I cannot thank you enough for making them.
If I'm not mistaken, the argument for PS2 keyboards being better came from older computer and the fact that PS2 was creating interrupts. PS2 would cause an interrupt so the processor would notice immediately what the user has press. With USB the key was not registered until the keyboard was pulled. On modern PC this is not a big deal, but on slower computers with poorly written software, the processor could be occupied doing other stuff until (eventually) checking if the user had typed something. Take all this with a grain of salt, as I cannot say that all this is 100% factually true. If it is, it wouldn't be difficult to imagine that in more demanding games, the processor would be occupied with running the game and would delay checking the user input, while a PS2 keyboard would just butt in with an interrupt demanding attention.
I don't think the CPU is handling the polling. I believe the UBS interface chip handles all of that and then generates an interrupt for the CPU when necessary.
@@xugro depends on the USB controller they have, which is a microprocessor in itself and could do the polling on each connected device and then generate an interrupt to the cpu on a new input packet. At that point the real limitation is the polling rate.
@@xugro What Nicholas is saying is there's a dedicated chip that polls and buffers keypresses and raising an interrupt on the CPU just like a PS/2 would. But i find that unlikely myself. Possible for sure but not likely. The OS has USB drivers and handles all that. If the kernel is hung up then something horrible has happened, something you aren't likely to fix with a keyboard.
I know that things are more complicated under the hood, that's why I said I don't know if this argument is 100% factually true. I know the USB is managed by a chip (a quite capable one these days), but I do not know in what conditions it generates interrupts to the processor. Plus, I think the first USB chips were not that smart and not sure if they could understand that they are talking to a HID device, that must pull every so often. I hope someone with more insight will show up to clarify some of this.
This was nicely done. I have broken down several protocols at this level for my team using a oscope. It is not a easy task to pull off, even for a simple keyboard interface.
recently got back into asic verification and have been struggling reading complex specs. thanks for making me realize how I overthink things a bit too much! this is a good refresher.
27:46 Oh, so that's why many keyboards require special inputs such as Fn+Home to enable n-key mode. A single USB data packet in low-speed mode can only contain up to 6 key presses, so either higher-speed mode should be used (like how the other keyboard shown does) or additional negotiations between the keyboard and the PC must be done.
This actually seems to be yet another misunderstanding. Refer to www.devever.net/~hl/usbnkro for the detail, but my understanding is that: what the n-key rollover switch does is sending a renegotiation packet, which can be actually done without human intervention. The actual reason is that the boot device has a reduced requirement which seems to be followed by pretty much every keyboard by default. It seems to me that the keyboard can renegotiate whenever the number of keys pressed cross the threshold of 6, so it's more likely that the keyboard vendors just prefer the safer way (to make users cumbersome).
This was awesome. I teach USB in my advanced digital design course. Students implement everything you just talked about in SystemVerilog. I’m going to assign this video. And, probably, excerpt some of it for class. Thanks so much!❤
I worked on several recent IEEE standards but USB was not one of them; however, I am very familiar with the standards. It's always nice to see how others break down the signals and look at the technology from a fresh perspective. The important thing to remember is that USB II has one very special attribute with streaming and that's all good until you realize it doesn't really check for and correct errors. That being said, it might be a fun new video to intercept the video transfer on a USB camera or something. I think doing a contrast between USB II and C would really show why we needed to upgrade to the new standard.
I will forever be impress by people who are able to take massively complex topics and somehow explain them without needing to boil them down. Love your work ben.
God thank you, I've been trying to understand USB for the past 2 weeks. EDIT: Skipped the setup process. D: Next time's gonna be adding an XHCI controller to the 6502 right?
This is fantastic! Absolutely love the depth of your explanations. You also do a fantastic job of simplifying and not filling with unnecessary technical jargon.
It's funny how Java's handling of keypresses is... EXACTLY what you see here. I mean, it makes sense, but it feels good to have some sanity in the computer world, even if it's just how keyboards work. Also, the computer can sync more often if you ask it to. I think 1khz is the fastest it does, which is almost as fast as PS/2. You can set the polling rate in Windows and on Linux based operating systems. I don't know about OSX, MacOS or whatever the Darwin based ones though. I assume you can. But I'm too lazy to google or even bing it.
I've been interested in mechanical keyboards and stenography lately, so n-key rollover comes up a lot. I thought limitations were only in hardware (like the error condition he showed with less than 6 keys), so was confused by things like keyboards gaining nkro with new firmware or ZMK working on adding support for it. Now that I know the basic packet is limited to 6 and nkro requires a different feature of the USB spec, that makes way more sense. I see he actually has a video just on that topic, so going to watch that now!
You're right, thanks to this kind of content (and awesome electronics) you can see hobbists around the world doing the craziest things, lately for example VGA. You can create a graphic card with an Arduino, in the '90 that was stuff for top engineers.
@@haczyk84 I lnternet is in grave peril and (serious) alternatives need to be put in place for freedom of information and communication. They are literally censoring elected U.S. presidents.
@@zteaxon7787 This seems like it would be impossible to do because all the hardware that is in use today is designed to use IP, and implementing a completely different protocol would make all these devices useless. LBRY is cool, but I will not support an internet where everything costs money.
UART is very similar to PS/2 except that there's no clock line, it's inferred from the agreed upon speed, and the transition of the start bit (which always goes from 1 to 0).
There are 8kHz polling USB mouses, some manufacturers will probably introduce 8kHz keyboards at some point. Whether people can actually tell the difference is another thing.
Expensive keyboards have drivers with configurable polling rates, though the highest frequency I've seen is 1kHz. It may be a hardware limit, but they have to be running on clocks in the MHz range to read the data anyway, I think the limitation is purely software.
I can tell you as a (piano) keyboard player that you can definitely notice a delay as short as 5-10ms when trying to play music (where extremely precise timing is absolutely crucial and you're most likely to hear the difference between where things *should* be and where they are). You can try it yourself by dialling in the audio latency / "buffer" time used by your audio drivers in a DAW. I very much doubt anything beyond 2ms / 500Hz resolution would ever be noticeable by a human being. That said, you can certainly see or hear two signals 2ms apart (the superposition will create very distinctive-sounding interference at specific frequencies, which is actually how narrow-band audio filters are made), but that's sensing differences in time (input), not acting with fine motor control (output) accurate to precise milliseconds.
@@gloverelaxis I agree; for rhythm games as well, a 16 ms (or about 1 frame) input delay is definitely noticeable. But latency more than an order of magnitude lower is going to be unnoticeable. At that point, any latency you might experience is likely to be caused by anything *other* than the actual keyboard.
Things we learned today:
1. USB is polling all the time
2. USB is insanely complex
3. There is always a fancier oscilloscope you don't have but really want
USB can push, but to my knowledge not for peripherals. Audio devices for example, can ask the host to push data IIRC.
The complexity mostly due to the need of supporting a bunch of devices. These device have their own needs and data protocols. USB separates this as classes.
Actually, that's sane, which is the opposite of insane.
I think USB3 is capable of pushing
Edit: USB 2 is capable of that too, it just takes the right keyboard/mouse that supports it
@@UltimateAlgorithm but what about the num lock, caps lock, and scroll lock lights?
I know But There’s ☝️ Scope That Beats All And That’s Your First ☝️
I’m Still Waiting For GOD To Bless Me With ☝️
Until Then I Continue To Pray Someone Throws An Old One Out Because They Upgraded.
"as is all to common with specs: it's got a lot of precision, but not a ton of clarity" I felt that. deep down in my soul, I felt that
Brilliant! Added to my list of burns!
I'm honestly amazed with what you just did. You literally took a signal out from a cable and interpreted it yourself on paper. You just made this so understandable and real to me. Thank you
I love this approach! I do a similar thing when I run into cryptic programming algorithms that I don't understand: pull out a notebook, and go through the code line by line until something clicks. It can be very tedious, but when I'm working with something I find especially opaque, it takes away all the abstraction and make things feel more "real".
The same sort of thing could be done by running the code through a debugger and watching a bunch of expressions... but there's something about manually writing things out on paper that makes information register better for me.
Yeah, Ben is the best teacher of this stuff that I've ever seen. He can explain anything in a way that just clicks with me.
The USB specification is one of the most readable technical documents I've ever seen. That will have helped, somewhat.
@@MixMastaCopyCat Booth's Algorithm to multiply negative numbers I used this approach !
I do this in my day job. Some times you just have to think it through like this...
It's so easy to pass these devices off as mundane everyday items, but when you really get into it, they really are magic designed by hundreds and hundreds of smart people, current and past.
I'm a electronic engineer student. I confirm, yes. The most simple thing, like, 'Oh this thing only switch on and off the light' yeah, no. Maybe this cost hundred of hours in research
If you go the magic route, you can actually get quite a bit deeper.
Q: How does that thing work?
A: It's magic. You see, those things are filled with rocks, and those rocks have microscopic glyphs written upon them. Those glyphs interact with each other in complex ways to produce the effects you see.
Technology is magical artifacts designed by wizards we call scientists.
Its disappointing to see everybody takes these hard earned technology as granted
@@johncochran8497 Paraphrasing a popular tweet from ages past: A computer is basically just a rock that we trapped lightning inside and tricked into thinking.
I am an electronics engineer and i cannot stress how much I admired you explaning this complicated topic as it was easy. If EEEN teachers are like you, all students could have succeeded easily.
I spent ~20 years developing learning technology for higher education and I have to say you have truly mastered it. I agree with everything said about how easily and quickly I was able to pick up details about USB - I love it. But your skill at breaking it down, basing your work on published references, (even though you likely already knew it) and walking use through the basics up to a more complex question was stunning. I've worked with maybe a hundred PHD / professional educators in engineering and many other fields. You far exceed anything I've ever seen. I'm fairly sure this is the 1st time I've ever liked and subscribed to any video/channel. Well done.
For PhD's it's not really surprising they don't excel at teaching, since they focus on research and academia, which unfortunately does not reward teaching skills at all.
Bluetooth keyboards and mice re-use the same HID protocol that runs on top of USB. In other words, you will see the same 8-byte packet for keypresses embedded inside of Bluetooth packets. I helped write the BT-HID specification.
How is the latency on Bluetooth? Probably more than 1ms
@@vadzimdambrouski5211 At best, it can be as fast as 800Hz (1.25ms) but this is not typical. Bluetooth, at least Classic Bluetooth, had 1600 slots per second where the master polls each device in the piconet and each device responds. If there is only 1 active BT device in the piconet and if the packets are short enough to fit in 1 slot, then the polling can go as fast as 800Hz since the master and slave will alternate slots. However, most Bluetooth mice and keyboards use Sniff Mode to schedule how often to be polled (vaguely how the bInterval value affects USB's Interrupt pipe polling rate). On the upside, the Sniff Mode polling rate can dynamically change during a connection. For example, a mouse may ask for a very fast polling in Sniff Mode while it is moving. After a few seconds of no movement, it may ask for a slower polling rate (save power, allow more traffic for other devices). After a minute of no movement, the mouse may ask for an even slower polling rate. After several minutes of no movement, it may even disconnect from the Bluetooth piconet and go to sleep. If moved, the mouse will reconnect and go back to the fastest polling rate.
@@ChrisDreher if BT can reach 800Hz, why almost no device use them? BT peripherals always feel slow compared to USB cable, or even dedicated wireless. This is especially apparent when using high refresh rate display. On these display, it is easy to tell between BT or USB (wired/dedicated wireless).
@@UltimateAlgorithm This is partially answered above but it mostly comes down to 2 main factors. First, Bluetooth is a bus that Bluetooth devices share. The more devices you connect over Bluetooth, the less bandwidth that is available per each individual device. This is why some dedicated/proprietary wireless mice can be faster (depends on the wireless technology). Second, just like the difference shown for USB in the video, how responsive a mouse can be depends on how the manufacturer tuned the mouse's Sniff Mode polling rate. For example, Bluetooth gamer mouse will have a faster polling for better responsiveness than a business mouse or low-end mouse that will have a slower polling rate to extend the battery life. Third, and not mentioned above, is that USB has much more bandwidth than Bluetooth. So while USB has frames at 1000Hz, which is slightly better than 800Hz for Bluetooth (a best case), USB bandwidth allows for multiple devices to communicate in a single frame but Bluetooth can only have 1 device communicate in a single slot. This tends to push mice manufacturers to use a slower polling rate over Bluetooth so that other Bluetooth devices don't get starved for bandwidth. Part of the reason for "one device per slot" is that encryption and wirelessness is complex, difficult, and inherently noisy (problems that USB doesn't need to deal with as much).
@@ChrisDreher that make sense, shame that most gaming devices opt for proprietary connection instead. No one is actually making fast Bluetooth peripherals. Maybe it's bad marketing in game industry, where Bluetooth keyboard and mice synonymous with high latency. Although this doesn't happen with gamepads (PS, Xbox and Switch). All use Bluetooth yet have very low latency, on par with proprietary keyboard and mice.
just hearing him say "that sounds right, that's what we're doin'" gives me so much hope
That’s pretty much what engineering becomes at this level of complexity… you convincing yourself that things seem correct based on logic rather than always being 100% sure of everything. It’s often impractical to know things absolutely.
@@ShALLaX It's just nice to know that even when you're ben eater you can't be 100% sure of everything
Strange
Uh oh nope
Ah yes, that great feeling that your theory or comprehension of theory seems to be right and mirrors in your test results :)
For USB hacking aficionados, worth mentioning that Wireshark (in addition to decoding network protocols) can also capture and analyze USB traffic! I used it to reverse engineer drivers for a silly USB-connected promotional pushbutton, as practice.
don't keep the knowledge to yourself like a hoarder, make a video! I'll watch!
pls share resources 👍
Currently doing exactly that to create a driver for an old scanner that isn't properly supported on Linux. I'm using Wireshark on Windows to figure out the communication protocol and then reimplement it under Linux. Such a pain in the ass. USB is so fucking complicated.
Yes, especially if you also enable to the USB PCap which is a Wireshark installation option on the later versions.
Worth scoping out, for sure!
it sucks with windows unfortunately, works fine with linux, not sure about macos
This is incredible. You're doing an entire school course's worth of teaching here.
God I hope not. This is pretty basic stuff.
@@stargazer7644 maybe, but school doesnt teach this way. They would spend weeks doing what he fit into a 30 minute video.
@@mrlithium69 Or leave it as homework for the student and move on to the next topic.
@@stargazer7644 just curious what your job is if this is simple?
@@TheFool2cool Electronics and software is my hobby. I design and build PC boards for fun. Protocol reverse engineering and troubleshooting is a common part of electronic design. When you're trying to get your microcontroller talking to some other piece of hardware, this is what you have to do. I studied electronics in school, but my day job is in Information Technology.
it is great to see more complicated protocols
I agree
Hope to see usb 3 sometime
There is no protocol that is more complicated than USB
up next, bluetooth
@@rasz I would also be interested in this, we didn't really talk about it in depth in my computer networks class at my school
In the gaming world, we call the issue where a number of keys can't be pressed at the same time, "ghosting." You were spot on with your analysis of why the smaller combination didn't work!
ua-cam.com/video/kOkV9BalNcw/v-deo.html
Factorio uses a lot of cords, and some ghost on cheaper keyboards.
My Logitech Lightboard XL only supports 2 keys at a time which makes it impossible to perform speedrun jumps eg. Amazing how this silly looking keyboard can handle up to 6 keys!
Any other youtuber: lets analyze this data on the oscilloscope
Ben Eater: let me screenshot the oscilloscope and print it out on paper.
The only thing I can possibly think of that could beat the visceral qualities of writing shit down on paper is MAYBE just doing that but in AR glasses.
@@williampasbrig3677 Yeah i like that he is writing it on paper too!
yeah. also, never heard of actual data export in csv format or similar? Which can then be properly plotted on a computer? Dude seriously, cropping screenshots together in freakin PS? Okay then.. BUT: Awesome video and explanation!
@@RandomUser2401tbh combining screenshots is probably easier than taking a csv export and plotting it in excel or something. You could combine that screenshot in mspaint in like a couple minutes or probably less
@@misaalanshori if you don't plot for the first time, plotting a csv is a matter of minutes. Exporting all the different png screenshot takes longer than that. Hint: Serious plotting is not done in Excel, but python, Matlab, Octave etc
This completely demystifies USB for me. It's basically no different to communication 40 years ago, but at much higher data rates with additional necessary EM protection
It's not smart, it's just stupid faster
@@AvenDonn I'm saving that quote, there must be some situation I can use it in
I mean sure, it's two wires of regular old copper, it's not like USB introduced new physics
In those 40 years, we went from serial for everything, to parallel when bandwidth was required (Laplink went so much better over parallel), and then with USB, back to serial for everything, only without giving up the speed. Then USB 3 sends us back to parallel (what do you think those extra 4 lines are for?). Time really is a flat circle.
Same thing with DSL: no different from 40+ years ago transmitting data over 2 wires of copper, just with advanced modulation techniques for much higher data rates.
I've been searching for a long time on how computers and their peripherals communicate on a very low, basically bit by bit level and this was an extremely well explained version of what I've been looking for. Thank you so much!
Ben Eater is like the Bob Ross of computer science.
lol, he's also good at explaining.
*Computer architecture/electronic engineering
This was a happy little journey into the USB protocol!
Perfect.
Ahahaaa very well said!
fun fact: the usb 3 lines on a Nintendo Switch dock aren’t properly shielded, so they can interfere with wifi/bt connectivity. some open source software for switch such as switchroot android have options to force usb2, which mitigates this.
ahahaha
the switch is such a cheapo device lol
So just use third party usb c to hdmi converter
Lol what, how did that get through the EMI comformity tests? Did they do it in-house? Independent labs usually catch those issues with no problem!
you mean shielded. Not insulated.
I love how this guy literally straight gets to the point without a 5 min intro
This thing is getting better
like for that 😂 face
This “thing”? You mean this channel?
He probably means he already knew everything that was taught before, but now things start to be interesting in a new way
Did you comment before you realized it wasn’t a breadboard computer episode?
It is radically changing the world
"It's got a lot of precision but not a ton of clarity" lol.
Bens uncertainty therory. A datasheet when observed, can either have a lot of precision but lacks in clarity or lacks in precision with a high level of clarity.
This video's got a lot of precision but also a ton of clarity.
That really is how a lot of specs are
@@markoap91 but that makes it 34 minuets long. So there is always a tradeoff
@@sayamqazi I know it can be hard to find the time to watch something like this. But if I have the time these kind of videos glue me to the screen and 34 minutes passes like 34 seconds. Plus, there are tons of watered down videos out there that explain things in simple terms so that you get the idea, there are not enough videos that go into this much detail to really SHOW you how something works and demystify it completly.
I first learned low level programming (between assembly and lower level hex for debugging).
Before starting my company and getting married, occupied a lot of time faking USB or serial devices with microcontrollers, just for learning purposes.
USB data structure always fascinated me, because it'speed is only limited by the hardware speed.
I mean, you can push it further and further, as long as there is time enough to receptor to acknowledge the signal ramps, there will be bit acknowledgement.
I admire your work teaching some low level computing to the young, Ben.
Thank you a lot.
Usb is the lethal weapon?
funny you say low level computing- to the average person even the display of an oscilloscope looks like magic.
Low level dosenot mean esay. It means near to hardware level.
What is the company you found?
Your company name?
One interesting thing to note between the USB and PS2 timings: Modifier keys and key releases take no extra bits on USB, but add extra bits on PS2. So in general USB is probably faster as long as it's full-speed and 1 ms polling rate, because you don't have the double/triple "packets" of PS2.
As far as i understand, is that PS/2 has a hardware interrupt in a proccessor, where a USB device has to wait untill it gets pulled and handled by software/processor. (but im not 100% sure)
@@marcoboot18 Did you even watch the video? lol
@@TheNini666 the video does not really address what he said.
USB keyboard can't tell independently if something changes. It can only answer when the host (computer) asks "what's up?". In USB host needs (AFAIK) keep generating those "what's up" requests, which is away from executing application code. PS/2 keyboard uses HW interrupt to tell the host when it has something to say.
I guess this does not really matter anymore. Maybe it did 20 years ago.
@@fl4shi238 I'm fairly sure the polling is taken care of in hardware by the USB host controller, which then uses an interrupt to notify the CPU of data when something is actually received and not just NAK'd. So the CPU really doesn't have to bother with the low level polling. There are many different host controller implementations though, so some may be different.
@@TheNini666 Marco is absolutely right. USB devices are polled by the USB host.
I love at 4:45 when you took a USB thumb drive to monitor the USB communication :)
It's USB all the way down!
now i wanna see how USB data transfer works, as opposed to HID in this video
and also...
IMPLEMENTING NTFS FILE SYSTEM ON 6502 when?
It's so universal!
@@Kitulous USB data transfer would be cool to see, as well as USB audio interfaces. Real time audio is one of the most complex things you can do over USB.
1:41 "it's got a lot of precision, but not a ton of clarity" you captured well what I find is complicating matters in technical topics frequently. Main message drowned out in a sea of details.
Yeah sometimes we're working on a microcontroller and we think initially there's no definitions, no basic overview of how it works. But after trudging through the details we find it's somewhere buried in paragraphs and sporadic. Sometimes it's just priority. Teach the person high level stuff overview then go into important details.
You know you've made it when the oscilloscope manufacturer lends you a $7000 device for your video :)
$7,000? Thanks for saving me a search and crushing my dreams in one comment ;)
And to think you can spend a measly $200 (student price) for a Discovery 2 and a Sigroc free download and do almost the same thing. And it does dozens of protocols.
@@katemoon7476 BeagleBone Black running BeagleLogic + sigrok would be even cheaper, but it's only a logic analyzer (100 Msps 12 channels) for 2.5V-3.3V digital signal (unprotected 3.3V digital inputs) unless you add an external level shifter, and user-friendliness is probably sub-optimal (though I haven't played with it myself yet). Though on the plus side, whenever you have no need for logic analyzer it's still a beaglebone you can use for other things.
@@katemoon7476 DSLogic Plus $100 (cheaper if you are willing to make RAM mod), 400Mhz and software is actually usable.
To be fair it probably cost them like $50 to produce.
"So hopefully you found that interesting."
Totally, it was amazing, so much detail, I love watching your videos. I've always been into simple electronics and computer programming, but they remained separate from each other, and watching your videos fills a void between the two and completes the picture.
If only I could get hold of your kits without extortionate UK import duty.
Nerd (Not a bad thing, Nerd = Smart And interested in learning)
Wow, this is just astounding. I'm currently back in school for an Electrical Engineering program, and I wasn't sure how well I'd be able to grasp certain comp sci subjects bc it's not my like, natural domain of understanding, but this channel makes so many of these topics so understandable but in a way that doesn't shy away from technically difficult info, and conveys it in such an intuitive way. absolutely A+ !
Reminds me of the days when I would lock myself in the room every day after returning from work, reading through the USB specs over and over again experimenting with a Cypress board, learning how to program the firmware so I could build my own keyboards, mice and joysticks. Now that I'm more than capable of doing that, I can't recall what exactly the physical frames look like. Thanks for making this video, helped refreshing my memory.
any books/documentation /learning path that you'd recommend?
@@LuckyST probably not. he full of horse.....
@@randokaratajev2617 how bout you then?
You sir are cool
@@LuckyST Depends on what you're trying to achieve.
If you're looking to get a general understanding, there's a PDF called USB in a Nutshell.
If your goal is understanding the protocol enough to be able to build your own USB hardware. Jan Axelson wrote some very cool books. There are books from other authors, but they all boil down to the official USB specification. Get the 2.0, not earlier, not the 3.x either, I’d explain later. A couple of class specifications and tables with all the necessary values will be needed further down the track.
It’s also recommended that you get the most familiar starter kit that you can find with a real USB core inside. FS (full speed) is good enough, HS would be an overkill and complicates things. Without picturing how you plan on altering the code for additional fancy features, try to run a few basic USB demo projects and get the kit running as intended, it should help you straighten up the dev environment and get you warmed up. Then comes the hardest part, intensive reading, you probably need hard copies of the most frequently referenced materials because all your fingers will come in handy as bookmarks to grab hold of / insert between the physical pages. Get the most comfortable mind map utility you have. I used a lot of blank sheets of paper back then, if you work more with digitized alternatives then that’d be better. You will run into a ton of terms and abbreviations that are both strange and related with each other. Before connecting the dots, you need to put them down somewhere like pins on a map. All the words read like nonsense to me in the beginning, it took me a lot of jumping around different paragraphs across different books before the Eureka moment dawned on me. And then I knew why the demo project was structured in a way to have all the strange structures organized in a handful of header files. All the descriptors and reports were just closely grouped there so it’s easy to customize them for new features.
If you’re looking to understand USB on a deeper level and tweak around the signaling, probably working on FPGA cores in the future, the aforementioned route should familiarize you with the application layer. I never looked this deep TBH, but there are two places to look into if you’re determined. The USB core library of the starter kit, and some low speed keyboard / mouse projects using general purpose IO pins as D+ & D- signals to build the protocol from scratch. Existing projects are mostly the work of gurus and they are well structured for the sake of better maintainability or whatnot, which adds to the complexity to understand them. If I had the time, I would’ve built the code from the ground up, trying to experience every step it took the guru to figure out how each tiny bit of detail adds up. Making a bunch of ugly code work would’ve been my first milestone, finding ways to optimize them into something close to the existing demos would be the next. By then, I would have really understood why everything is the way it is. And I’d be able to advance into the FS signaling, later HS. Gen 3 and Gen 4 won’t be like total gibberish any more.
I'm blown away by how much this one half-hour video does to demystify USB. Seeing how one approaches the problem, measures what's actually happening, and interprets the results; videos of this quality are few and far between.
Actually I am not a hardware guy, but i stumbled across this video and i could not stop watching it till the end. Its that well made. Thank you for your effort Ben!
Crazy what oscilloscopes have become... that thing can barely even be called oscilloscope anymore, it's a full-on hardware debugger!
They're just specialized computers, the highest end ones have surprisingly powerful GPUs just to try to emulate the ancient boob tube better...
@@NiHaoMike64 I'm from this millennia and so it took me 2 seconds to figure out what'd you meant by boob tube xD
Logic analyzers with a sketchy DSO onboard
@@NiHaoMike64 What is a boob tube? The only definition i found is TV, but it makes no sense to me...
@@Gigasimo456 Slang for CRT, what was used to make oscilloscopes before high performance ADCs became affordable.
Taking notes so I can remember all the specifics the next time a recruiter or hiring manager asks me what happens when I type a URL into a web browser...
If you generalize it to "a lot of things happen very quickly" it's broadly applicable to almost every question involving computers.
lol you could litteraly write a 1000 page book answering that question
@@tempest_dawn Stealing this
And they wonder why computer scientists love layers of abstraction. At the highest level of abstraction...yes stuff happens and it works.
Wow, such an interesting video, thank you for taking the time to explain this in both layman and expert terms 🌟
Next video: How to implement USB on a 6502.
Can we appreciate the fact that this is probably the first and the last "next video" comment that might be true.
@@techleontius9161 Yea, i just thought of using a Arduino instead to convert USB Keyboard to PS/2 Scancode
Yes. Maybe an Arduino Mini can be used here for reduce complexity. I use Arduino Micro for creating USB SNES and NES interfaces to PC or PS3. It's a real help to use it.
I used a ftdi ft313h to use usb on my 65c816/6502 build because the massive overhead of trying to process usb packets.
Would it even be fast enough to handle USB? I think it'd need to go into some type of buffer.
Thank you Ben for inspiring many of us to pursue this field. Your videos have, and will continue to be a source of motivation and interest for many generations of engineers.
This was awesome!
Fun fact: Some fancy keyboards might even appear as multiple keyboards, to get around certain OS' limits on how large a data block they can negotiate.
My laptop's touchscreen uses a USB interface and appears as 2 devices when I listed the inputs and I never knew why, I thought it could be some Linux driver shenanigans. Maybe this have some relation. Very interesting
Is that how they get the "N-key rollover"?
@@luizgfranca Linux ecosystem generally does not tend to go for shenanigans at least inside core components and system utilities. They just show all the ugly truths and dirty hacks as they are.
Gold I can't imagine what part of the USB association convoluted licensing platform this would be a loophole of.
@@KirillissimusDirty hacks? lol. Linux fails to support basic hardware functionality!! windows and macOS both do peripheral better than linux.
Thanks Emily for this good question! (and Ben for everything else)
For years I never understood how USB incorporates a clock signal. You're the first I've ever understood explaining such.
I feel like he's actually going to run doom on this thing at some point...
Technically nes used 6502 and people actually managed to run doom on it lol
We can only hope!
@@xugro no, they didn't. The "Doom on NES" runs on Raspberry Pi that's stuffed inside the NES cartridge, it runs doom and then inserts the image of the game in real time to the APU graphics memory... so it's not truly running on the 6502...
@@Mtaalas Thats.... a bit disappointing :(
the BBC Micro is able to run a 3D wireframe based game (Elite) pretty decently while running at only 2MHz, Ben Eater can easily upgrade the Computer to run at 10MHz (by simply using the same clock for the CPU and VGA Circuit) so it could probably run a simplified version of the DOOM Engine...
and with "simplified" i mean that to run at playable speeds you would likely need to lower the overall resolution and color depth to minimize the amount of data to be moved around
or maybe just aim for Wolfenstein 3D since that's only raycasting with some 2D Sprites thrown in the mix which is much easier to do than a complete 3D renderer
"so hopefully you found this interesting"
Oh BOY did I learn a lot from this video
Don't lie
@@sookmaideek I don't always troll but when I do, I troll hard... No wait xD
Just because I didn't see it mentioned in any other comments, it's worth mentioning that there are low-cost USB protocol analyzers (e.g., a Beagle USB box) that can capture and visualize USB packets at a high level for and for reams and reams of data. From a software standpoint, debugging this on a scope is much too low-level to be practical. That being said, I've had to work with USB device and host controller drivers at several points during my career, and I've never seen the actual USB protocol so simply and beautifully explained as in this video. This is pure technical gold. Thank you.
You are amazing at explaining things like this. I've been trying to figure out the protocol by myself occasionally and could barely catch anything, but your videos are always very understandable and knowledgeable on the topic. Keep doing gods work Ben!
GREAT Video! I love seeing the low-level detail of commonly used protocols. We, as end users, don't realize the technology involved in even the most seemingly simple protocols! (even after having learnt all these encodings at uni, seeing them in practice is even nicer!)
I really appreciated when you validated the CRC for us :)
OMG! This is amazing. I never thought it's done like that. I'm the head of a company, we design large ATS recruitment systems but watching such films gives me the greatest joy. It's simply brilliant how someone once designed it!
19:04 Interestingly, I think you can actually see where the line transitions control from the PC to the keyboard - If you look right after the red "end of packet" signal from the computer, you can see that the HIGH voltage of the line dips down a tiny bit. It also looks like the tops of the little "mountains" are a little bit more rounded when they come from the keyboard.
Yes, you can see this immediately when he lays out the printed copy at 5:24 or so. It's much easier to see on the D- line than D+, because D- is high when the keyboard takes over driving the line. This can actually be a lifesaver when debugging any multi-drop bus because it's so easy to get confused about who is driving at any given moment. In fact, a very useful debugging hack is to put a small value resistor either in series with the data line at one device or in series with that device's Vdd line (emphasis on the words "small" and "hack"). The idea is to lower the driver's Voh just enough to make the difference visible without compromising the data.
33:43 and since the user is equally likely to press a key at any point between polls the average latency is actually less than PS/2.
Really great video. Imagine if he continued to up the complexity and did stuff like PCIe or DDR.
depends on what the latency is between press and being ready to send the packet between keyboards
I feel like he'll eventually come to that
This makes me think the issue some feel with USB (Not me) might not be the latency itself but it’s variance. Instead of the predictable and repeatable latency of interrupt driven PS/2 they get subtle variations. In other words USB introduces jitter. I don’t know if a trained human can detect such minute differences, especially with all the other latencies involved in the modern gaming feedback loop.
@@rdoursenaud I'd be curious to see someone make an honest scientific (independent, randomized, double blind, ...) attempt to measure a performance difference that mattered in actual use.
With old cheap USB keyboards in the early days of USB (possibly with bugs and just without any improvements a modern gaming keyboard would have)? Plausible that you could measure a real world difference, though I'm not sure a typical gamer would show it. Might require an elite level player to matter.
But with a modern high quality well implemented gaming keyboard vs. a high quality PS/2? I'd be curious to see the experiment which would measure the practical difference.
I could easily believe that there are badly implemented gaming keyboards out there, though. And I could believe that thinking you had a better keyboard might have a psychological difference regardless of which you thought was better and which one you actually had. Double blinding would be important.
But ultimately it seems unlikely to me that you could measure differences that small. I'd expect them to be in the noise.
@@ratchet1freak Indeed there will almost certainly be at least some delay even for the PS/2 keyboard as I would imagine they probably implement some debouncing too. Human movement is pretty jittery at the micro scales which can be a problem right at the threshold of making or breaking the circuit. Adding a short delay before reporting the event helps prevent spurious input especially with the sort of soft switches you get in keyboards where there is no mechanical mechanism to ensure a hard transition from one state to the other.
As a mecathronics student, I WISH things were explained this well in every electronics class. Such a masterpiece.
Edit: spelling mistake
Wow you people really call those electrics classes. Must be electronics. Michi.
Cool Michelle, we can do friends ??. I love that subject mechatronics or animatronics.
@@matata3D2s yall thirsty af 💀
Having actually written low level USB drivers, it's fun to see the actual signalling that goes with the data.
That's really cool and nice sona btw :3
See the signal... I wonder if Geordi La Forge's visor connects over USB? Then again I suppose he can just signal for data any time
27:31 The smaller combination that results in an error condition is called ghosting and that's from the current going in an unexpected way in the key matrix. More expensive mechanical keyboards often have a diode on each key to limit the direction the current can go, but membrane keyboards don't have a way to do that, so it just detects combinations of column and row signals that are ambiguous. I think some gaming-oriented membrane keyboards do some sort of clever wiring in the commonly used gaming keys zone (say wasd, qwer, maybe by wiring those keys as a single row/column rather than having those specific keys in a matrix arrangement) to make the signal unambiguous in that zone without using diodes.
I've read that USB HID has a report protocol and boot protocol and the 6 keys + modifiers format is part of the boot protocol. Though I also read that fancier keyboards that support N-key rollover (NKRO) on USB often emulate multiple virtual USB keyboards (that presumably use the boot protocol) to send keycodes that are above the 6-key limit, rather than switching to the report protocol, and I have no idea why that is the case.
General-purpose keyboards usually have their matrix lanes built in a way that prevents ghosting when typing, at least in English. Cheaper gaming keyboards usually have different matrix lane layouts that prevent ghosting when holding down keys that are frequently used in gaming, such as WASD QE and the space bar. Higher end keyboards use diodes, higher lane count matrices, or individually addressed keys (for example fully-configurable RGB keyboards), and they either negotiate longer data packets, faster polling rates, or report themselves as multiple keyboards.
I watched this video for a project, I am literally goose bumped when you were hand decoding the usb code and the code just matched for the CRC and End of Packet code. Very very very impressed by what you did for this video, explored every curiosity I had about usb and ps/2. Amazing !
I just bought the Pi Pico and was looking for credible resources for how USB actually works because I have a project idea which depends on USB.
Very similar here. I took a dive into the spec but god is it lengthy.
Yup, same, I'm going to do a simple keyboard with raspberry pico and this video came in a really good timing
@@tomiesz usb is supposed to be universal *and* plug and play, so naturally the spec will be absurdly large. very similar story for bluetooth
the amount of use cases is directionally proportional to the size of the spec
@@tomiesz for just 2 data lines, it sure is!
I'm currently writing an operating system in ASM/C++, and I was about to write some drivers for USB, and this video will help a lot. Thank you!
I am still stuck at interrupts handlers and I can't figure out how to write them in c++.
@@ELYESSS There are a few solutions, but the one I always take is simply to write less complicated interrupt handlers in straight assembly, and more complicated handlers using calls from assembly back into C code. I believe GCC has also started adding some sort of support for writing interrupts directly in C/C++, but I haven't looked at interrupt handlers in probably a year so don't take my word for that.
Sweet!
Please show me the progress, maybe uploading videos on your channel about it. I've always wanted to watch and follow an OS being made, pretty sure other people are also searching for that, maybe even for guidance in their own projects
@@Perseagatuna Check out the OSDev Wiki page and Brokenthorn's OS Development Tutorials. There are lots of other links to follow out to others from there. You will find tons of resources on building an OS using those as a starting point!
@@benjaminmelikant3460 Thanks! I'm still in the process of learning C, and ASM looks way too complicated to me, but it also looks fun
This is one of the coolest things I have ever seen. Unless I'm just really bad at finding it it seems like their is almost no (or very little) content that goes in depth like this about physical layer and line encoding in such an accessible way.
Wow, another thing I've heard before and just didn't grasp, explained so perfectly that I _completely_ understand it. If I had teachers like you, the world would be a better place. Thanks for helping me to never stop learning. It really makes me feel good
Next video: Implementing 600+ pages USB protocol on your breadboard computer?
Surely lots of those pages are standards for the physical hardware and can therefore be ignored?
@@xTheUnderscorex oh, no no no, we need FULL standard, complete with USB-C support
@@PsychoBelka
lmao, lemme guess - you want USB3.1 thunderbolt support on the breadboard ?
@@cezarcatalin1406 dont you want it?
@@PsychoBelka implementing that is a hell of a ride xD. I put a USB-C on one of my PCBs and hooking up the Controller chip with all its data and power pins to the chip and the battery was already slightly more complicated than I thought, imagine going from zero to that.
I need this kind of in-depth, well-explained analysis on everything tech and science related! I'd watch it non-stop
I am really amazed, I've never seen the comunication of the devices with such detail, this is awesome, and the fact that you could explain it so well to someone like me that doesn't have an idea of this from the begining is also awesome, thank you for doing this kind of stuff and keep feeding our curiosity
BEEN WAITING FOR THIS FOR YEARS !!!!! Lets Goooooooooooooooooooo!!!!!!
I enjoy how you explain it on paper, really adds that analogue/low-level feel
Every time Ben uploads a video, I'm like "huh, I didn't know i wanted to know that."
that was the best lesson on how USB works
Such a good video. Just wow. Insanely high quality content, as usual. I really enjoyed seeing you decode the bits by hand, that was so cool. The fancy scope was a close second. Big thumbs up Ben 👍
Makes me feel better that not even Ben can plug in his USB keyboard correctly on the first try
type-c for the win!
@@victortitov1740 Today, it took me two attempts to plug in a type c cable.
There are still ways to get it wrong if you really want.
@@darranrowe174 im dying 😂
That's because USB-A is 4 dimensional: it doesn't fit on the first try, when you turn it around it still doesn't fit, but on the next turn around it finally works ;)
I wasn't even looking for this subject and also don't have that much knowledge in electronics or protocols, but I can say now I know how USB works in the very basic level. Your video is insanely good, man.
Wow, Ben so much of detail, really cool stuff there, very easy to understand. Thanks Ben
Interesting. Looks like endpoint descriptors can specify their preferred polling interval but Linux at least allows you to override that for kid/mouse/joysticks using module parameters. So maybe even cheaper keyboards can outperform ps2.
Good to know that Linux has this cool thing too.
1ms polling rate is the fastest allowed, though. You can't describe anything faster than 1ms
@@FelipeBalbi considering that these devices are meant to be human input devices, that's absolutely more than enough. Even 16ms might seem a lot, but it's still a relatively low delay as it's the same length of a single frame on a 60fps stream. Considering thay the standard human delay reaction to input is in the order of hundreds of ms, 16ms could be noticeable, but 1ms is negligible to say the least
@@maurofoti526 16ms is actually low for "hardcore games" :p watch this vid:ua-cam.com/video/heZVmr9fyng/v-deo.html
@@FelipeBalbi That is (mostly) true for Full Speed USB devices (i.e. 1000Hz is the max, ignoring some exceptions). However, on High Speed USB, the max polling rate is 8000Hz. If someone ever built a High Speed keyboard, it could theoretically be polled at 8000Hz. I don't know if any manufacturer ever built such a device, but it seems unlikely (haven't Google for those, though, so I could be wrong).
Thank you for making this. USB has always been something of a mystery to me, as has NRZI encoding, but you explained them brilliantly.
23:35 "... though you know they do make fancy oscilloscopes that will decode USB automatically. Unfortunately this isn't one of them."
I thought that the video will end here, then...
"BUT the people over Keysight were nice enough to lend me one that does!"
:D
That sounds like a very good way to advertise the Keysight product, since it would be immensely useful for USB hardware debugging...
I think decoding USB is software part
@@Gameplayer55055 Probably the most of added cost is for the software upgrade.
@@lifthras11r you can get a logic analyzer for much cheaper, since it isn't concerned with actually looking at the shape of the waveform, only the level changes! Then you can pull the data into software on the computer that decodes the data for you. It's neat!
@@lifthras11r ye
And there I thought the most complicated thing about USB was plugging it right the first time...
Although 31:35 made me chuckle.
With USB-C it's always plugged in correctly the first (and every) time😁
yeah they really took all the fun out of it
I believe USB-C does still have a D+ and D- that could be setup to be different, but it would have to be designed intentionally to be obtuse like that. So unless your EE is a troll, it's is for all intents and purposes symmetrical.
@@skaphanatic5657 Symmetry is required in the standard. If your EE makes it asymmetrical, then it's not USB-C.
@@coder0xff But there are crappy chineese USB-C to USB 2.0 adapters on the market that break the standard by only connecting D+/- wires to one of the 2 pairs. On some PCs they only work in 1 position and there is no way to know in which one until you try them and put some marking on the adapters yourself.
I just got into web development this year and UA-cam thought I'd like to watch you build a graphics card from scratch. UA-cam was right, but I also get a terrifying sense of existential dread when I think about my tenuous grasp on JS and also how much is going on "under the hood" that I'll never understand. You're a great instructor, but also this is all magic to me and I'm okay with that.
Drop that junk. Learn C++
"As all too common with specs, its got a lot of precision but not a ton of clarity"
amen
Another neat thing with USB keyboards is that on some you can actually increase the polling rate so you can get even less than the 1ms max delay that you showed at the end, at the expense of a bit more bandwidth having to be reserved on the bus, and the same goes for USB mice and their polling intervals
The thing is though, the game only processes user input during a certain phase of the game loop. That happens usually once per frame. So, if the game is running at less frame rate than the polling rate of the keyboard, there's no benefit to increasing the rate.
I remember doing that on Win XP, I think it gave you the option of 2khz polling vs about 100hz.. it did help the accuracy/feel quite a bit
@@chyza2012 Yes, but there's rarely a useful situation where a game that need the uttermost I/O speed needs to know what key was pressed a second ago. So even if it's buffered, the bottleneck will still be the games processing rate rather than the polling rate of the keyboard.
Isn't the polling rate coming from the computer? The keyboard only responds to messages is my understanding.
@@webosm6494 exactly, so on the computer you can increase the rate to keyboards that can handle the increased speed
"Understanding USB" for people who are too busy (or too intimidated?) to read the USB spec. Although I *used* many USB devices in the past (when I was still making living doing electronics) I never understood USB beyond (or below?) its applications level. Thank you for the enlightening tutorial.
I absolutely love the topics you cover in yo it videos. Other channels leave out so much in their tech explanations, but you take it to the next level and actually demonstrate how things work. Things like this, and your 8082 from scratch videos have taught me more about how computers work than any computer science course ever has.
(not saying these videos are a replacement for a CS class, but if you’ve taken some, and feel that things aren’t clicking, Ben’s videos just may be that final physical piece of the puzzle you need to put it all together)
Overall, phenomenal videos. I cannot thank you enough for making them.
That was so fascinating. As a software developer, I love seeing "behind the curtain".
This was a few orders of magnitude clearer than many uni classes on the SPI and I2C protocols. Thanks Mr. Eater.
If I'm not mistaken, the argument for PS2 keyboards being better came from older computer and the fact that PS2 was creating interrupts. PS2 would cause an interrupt so the processor would notice immediately what the user has press. With USB the key was not registered until the keyboard was pulled. On modern PC this is not a big deal, but on slower computers with poorly written software, the processor could be occupied doing other stuff until (eventually) checking if the user had typed something.
Take all this with a grain of salt, as I cannot say that all this is 100% factually true. If it is, it wouldn't be difficult to imagine that in more demanding games, the processor would be occupied with running the game and would delay checking the user input, while a PS2 keyboard would just butt in with an interrupt demanding attention.
I don't think the CPU is handling the polling. I believe the UBS interface chip handles all of that and then generates an interrupt for the CPU when necessary.
Wouldn't pulling the key presses be the job of the operating system?
@@xugro depends on the USB controller they have, which is a microprocessor in itself and could do the polling on each connected device and then generate an interrupt to the cpu on a new input packet. At that point the real limitation is the polling rate.
@@xugro What Nicholas is saying is there's a dedicated chip that polls and buffers keypresses and raising an interrupt on the CPU just like a PS/2 would.
But i find that unlikely myself. Possible for sure but not likely. The OS has USB drivers and handles all that.
If the kernel is hung up then something horrible has happened, something you aren't likely to fix with a keyboard.
I know that things are more complicated under the hood, that's why I said I don't know if this argument is 100% factually true.
I know the USB is managed by a chip (a quite capable one these days), but I do not know in what conditions it generates interrupts to the processor. Plus, I think the first USB chips were not that smart and not sure if they could understand that they are talking to a HID device, that must pull every so often.
I hope someone with more insight will show up to clarify some of this.
This was nicely done. I have broken down several protocols at this level for my team using a oscope. It is not a easy task to pull off, even for a simple keyboard interface.
recently got back into asic verification and have been struggling reading complex specs. thanks for making me realize how I overthink things a bit too much! this is a good refresher.
27:46 Oh, so that's why many keyboards require special inputs such as Fn+Home to enable n-key mode. A single USB data packet in low-speed mode can only contain up to 6 key presses, so either higher-speed mode should be used (like how the other keyboard shown does) or additional negotiations between the keyboard and the PC must be done.
This actually seems to be yet another misunderstanding. Refer to www.devever.net/~hl/usbnkro for the detail, but my understanding is that: what the n-key rollover switch does is sending a renegotiation packet, which can be actually done without human intervention. The actual reason is that the boot device has a reduced requirement which seems to be followed by pretty much every keyboard by default. It seems to me that the keyboard can renegotiate whenever the number of keys pressed cross the threshold of 6, so it's more likely that the keyboard vendors just prefer the safer way (to make users cumbersome).
@@lifthras11r Or they keep making it explicit to the user because marketing…
Big expensive oscilloscopes like that always amaze me. Such incredible machines!
they have a lot of fpga magic inside. the higher the frequency and accuracy, the insanely expensive they get.
@@stefanweilhartner4415 what is the price of that thing?
Its more of a logic analyzer, than an oscilloscope. Amazing piece of kit.
fun fact: the manufacturer of the one on this video (Keysight Technologies) was originally HP.
@@mel816 Who also bought out Agilent! At work still have some HP and Agilent equipment sitting in old test racks.
This was awesome. I teach USB in my advanced digital design course. Students implement everything you just talked about in SystemVerilog. I’m going to assign this video. And, probably, excerpt some of it for class. Thanks so much!❤
This was one of the most if not the most interesting video I’ve seen in a long time.
Oh my god. You are a very very brave soul. I wouldn't have even dared probing a USB signal.
USB:
- overly cluttered
- overly complex
- limited in a dozen ways
- too many revisions
- too many connectors
+ it kinda works
+ it’s everywhere
I worked on several recent IEEE standards but USB was not one of them; however, I am very familiar with the standards. It's always nice to see how others break down the signals and look at the technology from a fresh perspective.
The important thing to remember is that USB II has one very special attribute with streaming and that's all good until you realize it doesn't really check for and correct errors.
That being said, it might be a fun new video to intercept the video transfer on a USB camera or something. I think doing a contrast between USB II and C would really show why we needed to upgrade to the new standard.
That would require a super-pricy uxr
I will forever be impress by people who are able to take massively complex topics and somehow explain them without needing to boil them down. Love your work ben.
it's 1am, Saturday morning. I'm watching a guy delve into the intricacies and decode USB signals.
1am? It's 5am in here bro
God thank you, I've been trying to understand USB for the past 2 weeks.
EDIT:
Skipped the setup process. D:
Next time's gonna be adding an XHCI controller to the 6502 right?
Awesome, I've always wondered about the PS/2 vs. USB response differences. Great work as always Ben.
This is fantastic! Absolutely love the depth of your explanations. You also do a fantastic job of simplifying and not filling with unnecessary technical jargon.
- "I had an exam yesterday, keep that digital stuff away from me!"
- "Ben uploaded."
- "LEMME WATCH IT NOW!"
It's funny how Java's handling of keypresses is... EXACTLY what you see here.
I mean, it makes sense, but it feels good to have some sanity in the computer world, even if it's just how keyboards work.
Also, the computer can sync more often if you ask it to. I think 1khz is the fastest it does, which is almost as fast as PS/2. You can set the polling rate in Windows and on Linux based operating systems. I don't know about OSX, MacOS or whatever the Darwin based ones though. I assume you can. But I'm too lazy to google or even bing it.
I love that you pulled it out on paper and decoded it by hand! That was a really helpful - and unexpected - visual.
I've been interested in mechanical keyboards and stenography lately, so n-key rollover comes up a lot. I thought limitations were only in hardware (like the error condition he showed with less than 6 keys), so was confused by things like keyboards gaining nkro with new firmware or ZMK working on adding support for it. Now that I know the basic packet is limited to 6 and nkro requires a different feature of the USB spec, that makes way more sense.
I see he actually has a video just on that topic, so going to watch that now!
Imagine if the quality and contents of this information was readily available during the Commodore 64 days... where would we be now?
You're right, thanks to this kind of content (and awesome electronics) you can see hobbists around the world doing the craziest things, lately for example VGA. You can create a graphic card with an Arduino, in the '90 that was stuff for top engineers.
We should appreciate Internet.
@@haczyk84 I lnternet is in grave peril and (serious) alternatives need to be put in place for freedom of information and communication.
They are literally censoring elected U.S. presidents.
@@zteaxon7787 who tf is 'they'? who's censoring Biden?
@@zteaxon7787 This seems like it would be impossible to do because all the hardware that is in use today is designed to use IP, and implementing a completely different protocol would make all these devices useless.
LBRY is cool, but I will not support an internet where everything costs money.
This was cool. Can you do one on UART as well, please.... thanks in advance
well. to use with the 6502, you dont need to understand any of it. the more you know
the ps/2 video works with uart
UART is very similar to PS/2 except that there's no clock line, it's inferred from the agreed upon speed, and the transition of the start bit (which always goes from 1 to 0).
UART is simple enough that any article you read about UART should explain everything in less than 10 minutes
There are 8kHz polling USB mouses, some manufacturers will probably introduce 8kHz keyboards at some point. Whether people can actually tell the difference is another thing.
There will definitely be people who will claim to tell the difference.
@@timseguine2 But only if you use gold-plated data cables.
Expensive keyboards have drivers with configurable polling rates, though the highest frequency I've seen is 1kHz.
It may be a hardware limit, but they have to be running on clocks in the MHz range to read the data anyway, I think the limitation is purely software.
I can tell you as a (piano) keyboard player that you can definitely notice a delay as short as 5-10ms when trying to play music (where extremely precise timing is absolutely crucial and you're most likely to hear the difference between where things *should* be and where they are). You can try it yourself by dialling in the audio latency / "buffer" time used by your audio drivers in a DAW. I very much doubt anything beyond 2ms / 500Hz resolution would ever be noticeable by a human being. That said, you can certainly see or hear two signals 2ms apart (the superposition will create very distinctive-sounding interference at specific frequencies, which is actually how narrow-band audio filters are made), but that's sensing differences in time (input), not acting with fine motor control (output) accurate to precise milliseconds.
@@gloverelaxis I agree; for rhythm games as well, a 16 ms (or about 1 frame) input delay is definitely noticeable. But latency more than an order of magnitude lower is going to be unnoticeable. At that point, any latency you might experience is likely to be caused by anything *other* than the actual keyboard.
LOVE yoooooouuu man. This is the thing everome was dying for 🔥🔥🔥🔥🔥🔥🔥🔥 this will me greatly more useful than other interfaces
Thanks!