Main > Main Forum

USB vs PS/2 vs COM vs LPT

<< < (20/43) > >>

Derrick Renaud:

--- Quote from: MonMotha on September 24, 2010, 01:21:27 pm ---My common solution for direct parallel port access is a little program called "userport" and those routines above, but there are probably better methods, now.  I researched that method nearly 7-8 years ago when XP was fairly new, and I was still running Win2k.  At minimum, there are solutions that don't require opening up port ranges to every application, now.

--- End quote ---

Nice, I'll have to try it.  I like that they supply the source code.

Hoopz:

--- Quote from: CheffoJeffo on September 24, 2010, 11:26:45 am ---As much as I hate to admit it ... Hoopz was right ...



--- End quote ---
QFT

 ;D

And sweet Moses, I wish I understood 1/10 of what MonMotha is talking about.  That dude knows his stuff.   :dizzy:

Driver-Man:

--- Quote from: Derrick Renaud ---MAME (since the last input re-write) just takes all input data that happened in the last frame of real time, and interpolates it for when the game asked for it.

--- End quote ---

Interpolates input? Sheesh mamma, then it's worse than I thought. Can you point out what file, in what function can I see the implementation of what you're are talking about?



--- Quote ---In other-words, at 125Hz poll rate, the worst case delay is 0.008s.

--- End quote ---

You are talking about USB latency, and I'm talking about the maximum rate at which the keyboard controller can supply scan codes. You are assuming you can poll unlimited number of scan codes "all at once" every 0.008 sec, while not taking into account that each of those codes need first to go through port 0x60 and be set in buffer, one by one. Plus there is additional time spent with emulation and conversion of USB packets to PS/2 protocol, and there are other "lags" or "interrupts" that might have greater impact yet. -- If there was not multiple simultaneous keys pressed then 125Hz would be sufficient latency, but again we are not talking about latency, we are talking about maximum bandwidth of the keyboard controller.



--- Quote ---Except to say RandyT and AndyWarne know what they are talking about.

--- End quote ---

KeyWiz guy does apparently know about (some) USB keyboard limits. I see him stating on his website that's exactly the reason why he only makes PS/2 keyboard interface, and not USB. For USB he actually uses only game-pad controllers and joystick interface, not keyboard encoders at all. -- This is exactly what I want to underline here too, so I have no idea what was his point arguing against me when we actually agree, and why is he so shy to say it here out loud.



--- Quote ---There is a difference between using a hacked USB keyboard, and a good USB input board that sends keyboard data.

--- End quote ---

That is under question. If it turns out that keyboard controller is the common bottleneck, lower than the limit of 6 key at the time, then whatever difference left between them would be much less important or completely irrelevant. -- What I agree with is that there is a difference between USB keyboard encoder device and USB game-pad encoder device since joysticks would not need to use keyboard controller and all the 'scan codes' crap, hence joysticks have potential to pack their information more densely, and dispatch the whole  batch of current state data in smaller time-window. -- Whether that batch of data will manage to arrive in time for the corresponding frame, or will it lag behind the "real-time", is also not the issue we are discussing, yet, but the point here is that all this is far, far away from "simple" and "obvious".




--- Quote from: MonMotha ---I'm guessing you built yours as a DOS application.  When you run a DOS application on NT, it actually runs inside an emulation/compatibility layer known as NTVDM.

--- End quote ---

Let's not talk about Windows quirks but whether the USB keyboard data indeed goes to port 0x60 and into the keyboard buffer first, one by one, or not. I agree the fact my program works does not prove it really, but it's your turn now, you have presented no evidence at all.



--- Quote ---This emulation would also include the keyboard controller.

--- End quote ---

No, emulation is in hardware/firmware. Please start providing some sources and reference to go along with your statements and claims, like this:

http://wiki.osdev.org/PS2_Keyboard
- "The Keyboard Controller (KBC) is located on the mainboard. The name is misleading because the Controller does more than controlling the communication with the hardware on the keyboard. In the early days the controller was a single chip (8042). As of today it is part of the Advanced Integrated Peripheral."

- "USB Legacy Support... To remain compatible with old software, the mainboard emulates USB Keyboards and Mouses as PS/2 devices. This is called USB Legacy Support."

- "Because the implementation differ by manufacturer and mainboard there are flaws and sometimes even bugs... Some emulation layers also handle the communication with the real PS/2 connectors regardless of any connected USB device. So maybe not all capabilities of the PS/2 connectors and devices can be used."

DillonFoulds:
I still don't know what the point of this whole thread is.

Let me sum up my understanding... Driver-Man insists that the usb and/or ps/2 inputs aren't fast enough. Common thoughts disagree. I can see Driver-Man's side on this, as he's trying to let us know polling rates aren't quite as fast. While I'm not knowledgeable enough to say one way or another if this is accurate, I'd have to say that the difference would be highly irrelevant.

I've played all sorts of fighters on both my GPWiz40 and my ipac 4, as well as console games, and I've yet to notice any dropped inputs. We get pretty competitive when it comes to games like Mario Kart 64 or Super Smash Bros, and we'll have 4 people driving, power sliding (hop, waggle joysticks) , and dragging shells all at the same time, and still haven't noticed any dropped commands. Not sure that a standard keyboard controller (or any matrix-based system for that matter) could withstand it without dropping a few keys.

Not saying that an LPT device couldn't handle it, just saying I dropped only 25$ on my GPWiz (ipac4 was a bit pricier, at 65$) and they both do a fine job. Not sure an LPT solution would be affordable to start, but I'd be willing to be proved wrong?

JustMichael:
Driver-Man,
I have no idea where you get all your misconceptions but you definitely have a ton of them.  You seem to think that software is written like it probably was 15 years ago or so when USB was starting out.  I wouldn't be surprised at all if way back then the USB data was converted to ps/2 for compatibility sake.  Today, USB doesn't go to port 0x60 in windows nor does it get "converted" to ps/2 protocol.  Your misconceptions with USB bare little resemblance to the reality.  You can read the specifications if you wish as they are online but yet you choose not to for some reason.  You might even try and design your own USB keyboard controller chip.  I think both Cypress and Microchip have software applications to help people design and program their microcontrollers.  Perhaps after that you will have a better understanding of microcontrollers and USB.


--- Quote ---You are talking about USB latency, and I'm talking about the maximum rate at which the keyboard controller can supply scan codes.

--- End quote ---

The USB specification already determines the maximum rate that a USB keyboard controller can supply scan codes.  That maximum is set by how fast the USB connection is.  For example, a USB 1.0 device can't transmit faster than 1.5Mhz (roughly 180K/sec).  Simply put, you can't send stuff faster than your connection is.  Well I already provided you with an example that I am sure is lower than the theoretical limit but here it is again:


--- Quote from: JustMichael on September 20, 2010, 03:37:34 pm ---Now let's look and see if USB can transmit all the keys pressed at once.  Let's use the slowest USB specification USB 1.0, which transmits around 1.5Mhz which translates into about 180 kilobytes per second.  Lets divide that 180K by 125 (default polling rate in windows) and we get 1.44K or 1,440 bytes.  Now let's toss away 1/2 of that to "overhead" (yes I know overhead stuff is nowhere near that high).  That leaves 720 bytes.  I think 720 bytes is more than enough room to transmit what keys are being pressed.

--- End quote ---

And farther down in the post:

--- Quote from: JustMichael on September 20, 2010, 03:37:34 pm ---In the example I listed 180K per second not 720 bytes per second. I listed 720 bytes being transmitted each time the USB device is scanned.  Let's say every key has 4 scan codes (or bytes).  This would mean that the USB device could send up to 180 keys every time it is asked.

--- End quote ---

This would be:
180 keys x 125 (the polling rate) = 22,500 keys per second for my example.

Now AndyWarne said the I-PAC is sends its data to the computer 500 times per second (500hz).  The I-PAC4 has 56 inputs (according to the website).
56 keys x 500 = 28,000 keys per second.  I am sure he could make the microcontroller go faster but why?  I don't know about you guys but for a keyboard controller that sounds plenty fast to me!  Do I own a I-PAC?  Yes I do and I am extremely happy with it.

Now if you mean how fast a microcontroller can read its own inputs:

--- Quote from: JustMichael on September 23, 2010, 11:08:09 am ---If you mean how fast the microcontroller can read its own input pins, that would be a function of the microcontroller's architecture, its programming and how fast its cpu clock is.  The speed will be less than the cpu clock because the microcontroller would read the input pin(s) and store what it finds (similar to reading the LPT port and storing what you find).  You can check the data sheet of a microcontroller to find out its cpu speed.  Cypress Semiconductor and Microchip Technology both make USB microcontrollers.  If I remember correctly, the I-PAC uses a microntroller from Cypress (AndyWarne if I am wrong please chime in).

--- End quote ---

Simply put in order to find out the absolute maximum a keyboard controller can read its own inputs you will have to make your own and then the information will only apply to that device.  I don't think any of the manufacturers will let you read the source code for their devices.  I know I wouldn't.

By now even I have reached: :blowup:

Why do I feel like I am trapped in a Jerry Springer episode?
:jerry :jerry :jerry :jerry :jerry :jerry

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version