Main > Main Forum

USB vs PS/2 vs COM vs LPT

Pages: << < (4/43) > >>

severdhed:

ok, but this will be nearly irrelevant in the near future. very few motherboards are made with LPT ports anymore.  i know most poeple arent using new computers for mame PCs, but still, in a few years this won't matter. for instance, using newegg.com as an example.  they list 201 AMD motherboards, 17 of which have an LPT port.  they list 332 Intel motherboards, of which 35 have LPT ports.  that is just 52 boards out of 533 (less than 10%)that have an LPT port, and I'm sure that number will be decreasing steadily over the next few years.  PS/2 ports are also going away as well.  Alot of the new boards that I see either have no PS/2 ports, or 1 combo port that can work for either a mouse or keyboard.  the truth of the matter is, that whether you like it or not, USB is going to be the only option before too long, and judging by the performance of the USB devices i have used, there is nothing wrong with that.

Osirus23:

The motherboards don't have an LPT connector on the backplane but they still likely have the onboard connection for an adapter.


Thenasty:

Some MOBO's now don't have COM ports anymore (I'm sure you can buy an addo serial PCI card).


Rick:

I'm confused.  Is Driver-Man saying that there's a bottleneck whereby two players on one game *could* get a 'mis-click' on one, due to the USB/PS2 port not reading quickly enough?  It seems to be an easy test, to me.  Open up a fighter, and player one press and hold the joystick right, and player two press and hold the joystick left.  If the on-screen image ever falters, boom.  We might just have some lag.  If not, it sounds like it's working fine to me.

RandyT:

Interesting diversion, but full of bad conclusions.

The PS/2 keyboard port can operate at around 30,000 bits per second.  Most keys take only 11 bits for a "key down" (1 piece of keyboard data), but take twice as many for a "key up".  Extended keys take an additional piece of data for each transition.  The benefit of this type of scheme is always having full control over key states, thereby eliminating the possibilities of "stuck keys" and giving one the opportunity to create a device in which every single key on a panel can be pressed at the same time and accurately tracked without interference between keys, or from the CPU.

If you do the math, you will see that 30,000 / 11 = 2727 pieces of keyboard data per second are possible.  Divide that by 60, and you get up to 45 pieces of keyboard data per frame.  As it's physically impossible (and practically useless) for a user to both press and release a single button in the span of a single frame, it doesn't pay to think about the whole key transition process as a solid block of data.  What makes more sense is to view the 45 pieces of data available as the "1-frame-window" in which to assemble the required data for that one frame of the 60hz poll.  That is buttons being both pressed and released, each using whatever portion of that space they require.  And as 1 frame is a very small amount of time ( 16ms, or 60 samples per second, to be precise) the odds that the data space for that time frame will be exhausted by even 4 players bashing madly at controls will be infinitesimally small, as they would need to be acting in virtually exact unison, generating many events each within that tiny amount of time.  And because all control actions are fully buffered, the data is smoothly streamed at the highest possible speed, even when the action gets intense.

So your scenarios just don't hold any water, and the "mario example" is just absurd.  And while fighters do require fast timing for special moves, what is also very important is sequence.  If the events are provided in parallel, as a packet of keyboard data is over USB, there is no guarantee as to the sequence the data will be acted upon.  Again, this is only a concern with data contained within the time frame of a keyboard data packet, not 1 frame of the game.  So again, not much of a concern.

If absolute speed is your desire over USB, then there is nothing better than a gaming controller.  For instance, our GP-Wiz controller can report the state of all 40 inputs in an 8ms time frame. In other words, it can do it twice for every frame of a 60hz sampling game, which is 200% of what is required.  But because a select handful of apps look for keypresses only, it gives up a little compatibility.  Thankfully there are very few where this is the case, and there are GP to KB apps to pick up the slack.

And now we get to the printer port...

Because of the size and expense, these are disappearing far faster than legacy keyboard connectors.  As Saint noted, the PS/2 keyboard ports have remained, even while the PS/2 mouse ports haven't on many new PC's.  There's a reason for this.  The keyboard is a very intimate part of the interaction between user and computer.  Some will go to great lengths to keep their current keyboard, even when every other component of their system has been replaced.  It's also very inexpensive to implement and the footprint is small.  The PS/2 keyboard port will be with us for quite some time because of this dynamic.  The printer port, on the other hand, is easier to see vanish for most users.  The cables are big and clumsy, and printers have a tendency to die quickly (compared to keyboards) and there are usually lots of advantages to upgrading them.

And then there's compatibility.  If the game supports the interface, then great.  What if it doesn't?  The drivers out there don't seem to be available for Windows 7, and work has been discontinued.  If you are indeed the "driver man", then put your money where your mouth is and develop a cross platform driver that integrates perfectly with the current operating systems and can output keyboard events properly, even with the RAW input model, because this is what the keyboard devices do.  Anything else, and all you have is an inferior version of an HID gaming control that has far less direct compatibility.

I won't even bother going into the benefits of parallel processing provided by dedicated controllers, as that is mostly academic with newer systems.  But if you want to be academic instead of practical, we can do that too.

RandyT

Pages: << < (4/43) > >>

Go to full version