Main > Main Forum
USB vs PS/2 vs COM vs LPT
Marsupial:
--- Quote from: JustMichael on September 27, 2010, 09:19:12 pm ---And what exactly are these two programs supposed to "prove"? ???
--- End quote ---
that Driver-Man is a troll.
Driver-Man:
--- Quote ---And what exactly are these two programs supposed to "prove"?
--- End quote ---
Statistics. Relax, it's over. Ask MonMotha to explain.
--- Quote from: AndyWarne ---You have missed out the captures above this which show no keys pressed, the ones which send all zeros.
--- End quote ---
There was nothing above, that was the first set of data - 5 keys down.
YOU:
ME:
--- Quote ---So, we start with no keys pressed (all zeros).
--- End quote ---
No, you start with 5 packets, each 32 bytes long, and each holding absolutely the same information saying 5 keys are down.
--- Quote ---Then the next packet, 2ms later, when all keys are pressed, contains all the keys. Thats all we need to know.
--- End quote ---
No, you first send one packet with all 5 keys down, then 2ms later another one with that SAME information, and again, and again, and again. Then you release those five keys and then you again send 5 packets of 32 bytes, this time all zeros, 5 x 32 = 160 bytes just to signal 5 keys went up.
--- Quote ---But for info, now, after that another 4 packets are sent, with all the keycodes. These form no part in the process as the host already knows all 5 keys are pressed. These packets are simply repeating data already sent. So, why are they sent? Well... the host polls the device at 2ms intervals.
--- End quote ---
No, there is no traffic going on EVERY 2ms, ONLY when you press or release a key, it is clear from the time intervals. -- You have steady 2ms intervals when you make simultaneous 5 key press, but you can then notice a longer pause when you hold down the keys before you release.
--- Quote ---I could just send one packet every time there is a change but I send 5 (or more accurately I respond to 5 requests from the host). There is no advantage to be gained by sending only one packet so I send 5. This does not slow the process as the host gets the 5 keys in one go, on the first packet. The others are just to "make sure".
--- End quote ---
How can you control that number of packets sent? Encoder? Driver?
JustMichael:
--- Quote from: Driver-Man on September 27, 2010, 10:01:26 pm ---
--- Quote from: AndyWarne ---You have missed out the captures above this which show no keys pressed, the ones which send all zeros.
--- End quote ---
There was nothing above, that was the first set of data - 5 keys down.
--- End quote ---
I am guessing his software program is smart enough to skip the zero packets before the first keypress. I would bet this is why we missed out on those zero packets.
--- Quote from: Driver-Man ---
--- Quote from: AndyWarne ---So, we start with no keys pressed (all zeros).
--- End quote ---
No, you start with 5 packets, each 32 bytes long, and each holding absolutely the same information saying 5 keys are down.
--- End quote ---
He was telling us about the packets that came before the ones shown.
--- Quote from: Driver-Man ---
--- Quote from: AndyWarne ---Then the next packet, 2ms later, when all keys are pressed, contains all the keys. Thats all we need to know.
--- End quote ---
No, you first send one packet with all 5 keys down, then 2ms later another one with that SAME information, and again, and again, and again. Then you release those five keys and then you again send 5 packets of 32 bytes, this time all zeros, 5 x 32 = 160 bytes just to signal 5 keys went up.
--- End quote ---
He sends the packet more than once to ensure that it gets there intact. Why 5 times? Arbitrary number I guess.
Or possibly:
2 times would be sufficient in case the first got "lost" but then you multiply that by "the rule of 2 1/2" and you get 5 times. The "rule of 2 1/2" I refer to is a "rule" I learned a long time ago. First you figure out how much whatever will be enough for your needs, multiply it by 2 1/2 and you're guaranteed to have enough (even under unforeseen circumstances).
--- Quote from: Driver-Man ---
--- Quote from: AndyWarne ---But for info, now, after that another 4 packets are sent, with all the keycodes. These form no part in the process as the host already knows all 5 keys are pressed. These packets are simply repeating data already sent. So, why are they sent? Well... the host polls the device at 2ms intervals.
--- End quote ---
No, there is no traffic going on EVERY 2ms, ONLY when you press or release a key, it is clear from the time intervals. -- You have steady 2ms intervals when you make simultaneous 5 key press, but you can then notice a longer pause when you hold down the keys before you release.
--- End quote ---
Just because he only shows you part of the traffic doesn't mean the rest of the traffic doesn't exist. AndyWarne even stated he turned off tracking of the NAK responses:
--- Quote from: AndyWarne on September 27, 2010, 11:38:47 am ---So, why are they sent? Well... the host polls the device at 2ms intervals. Usually the device will send a NAK unless it has some data to send. The trace does not show the NAKed polls as I have turned off "Disply NAKed transactions" in the view to avoid clutter.
--- End quote ---
The NAK responses are all the 2ms responses that aren't being shown. There would be 85 NAK's responses alone between the first set of keys down and the keys up. I think showing those 85 responses would be a big waste of space.
--- Quote from: Driver-Man ---
--- Quote from: AndyWarne ---I could just send one packet every time there is a change but I send 5 (or more accurately I respond to 5 requests from the host). There is no advantage to be gained by sending only one packet so I send 5. This does not slow the process as the host gets the 5 keys in one go, on the first packet. The others are just to "make sure".
--- End quote ---
How can you control that number of packets sent? Encoder? Driver?
--- End quote ---
I think you are confused again and AndyWarne even clarified his statement. There is only 1 packet being sent each time the host makes a request. He just sends a data packet that has the keys as a response to the host's request and then resends that same data packet to the next 4 requests.
riley454:
MY HEAD HURTS :blah:
Can someone please simplify what is the best way to connect a mame panel that plays everything from space invaders to mortal combat 4 up to a pc without the geek talk?
CheffoJeffo:
--- Quote from: riley454 on September 28, 2010, 07:24:32 am ---Can someone please simplify what is the best way to connect a mame panel that plays everything from space invaders to mortal combat 4 up to a pc without the geek talk?
--- End quote ---
Sure -- RTFW.
:afro: