Main > Main Forum

USB vs PS/2 vs COM vs LPT

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

Marsupial:

Driver-man, I see where you're going and understand you still haven't found someone that can debunk your misconceptions... but the fact is, there ARE misconceptions in your logic.



The issue of parallel VS serial (being COM ports, LPT ports, USB, firewire or whatever - USB isn't the best out there) is old as can be. There are EE courses specializing just in that. Really, there are, and high speed digital system classes aren't the easiest ones out there.

For starters, parallel has limitations. It is a case of speed against distance. Really. At high speed, you are limited of how quick and how far you can send the parallel signals if you want to ensure they are all synchronized, to ensure you can read all the parallel bits together and reform the original data. The longer the bus, the slower you can send data to it. That's even without talking about interference, crosstalk, capacitance, wire configuration and all that jazz. Plus, you need control bits to ensure data validation.

That is why they made multiplexors and protocole, and why serial became so popular; more control, less data loss, higher speed.  Look at the emergence of serial ata! Remember also that most parallel ports on computers don't run at high speed, and can even be handles by plug-in USB devices.

But all that isn't the main flaw in this whole parallel VS serial logic.


The main issue with parallel arise with the number of I/O you want to use. A normal LPT port has 9 IO plus control signals. for a two player / six button control pannel with 2 starts and no admin buttons, you have 22 separate inputs, and therefore would require 3 LPT ports, or another type of parallel port (remember LPT isn't the only one out there.)
Or you go with multiplexing, but then you loose the whole authenticity point.

Then again, for authenticity, you'd need the emulator to read the button state directly from the buttons, not trough a conversion service, so that is not even a valid point until MAME handles the ports themselves.  

Whatever happens, the buttons are read somewhere, and made available for the emulator to poll when its ready. If your solution includes any type of buffering, then being serial, or parallel, doesn't really change the end result that it is not authentic.




Another thing to take into consideration, is that the USB channel won't be polling the buttons, nor will the host so we don't care that USB1.1 is going at 12Mbits/s. There is a microcontroller on the device side that polls the buttons at higher speed and sends the data in a formatted grid as a one shot to the USB host, and the driver will then sends all the data at once in memory, which is similar in the end to what you see in true unbuffered parallel from a system perspective. To the eyes of the emulated PCB, the data is just there when it polls it, no matter how it was set.

Remember: the emulator software is running at higher speed then the PCB it emulates, so the difference is negligible. You know what? the games don't constantly look at button states, it polls them one at a time somewhere in their main loop, and builds a state grid, passing by a debouncing algorythm. When that happens, the button represention within memory is good ennough for the emulator not to care who sends it in.


Yes, there are more steps between the buttons and the CPU using it using USB then a CPU parallel bus. But, the game polls a MAME representation of the buttons status as opposed to poll the actual buttons. So we don't care, really. No, we don't. For the emulated PCB, its the same. It really is.




As being mentionned earlier, if you're after authenticity, the only way out is to own authentic hardware. Otherwise, emulation does an excellent job.

What you seem to be confused with, however, is the ghosting effect of some keyboards.

Some keyboards (most) don't have a physical button for every single keys. They use a physical grid, and from the various signals it reads, extrapolate what buttons are being pressed. This is good for typing, but for keymash like what we see with multiplayer games, that cas cause problems: some keys virtually "hides" others as they use the same base grid signals, resulting in some buttons being omitted from the final result.

This is completely bypassed with keyboard adapters, because they rely on specific switch for every buttons, and poll them at high speed.

Now... I already know what you want to answer right now, if you haven't already started an answer before even finishing to read the whole post.
"can you prove it".

Well, you know, trolls asks for pre-chewed answers, proof from the president himself. Do your homework and get documentation from your own source that you find reliable... there are standards, read up IEEE publications, look at specsheets. People have been doing it for years with great result, there's no rocket science in looking up data. So before stating that what's being said isn't fact, try to see for yourself.

MonMotha:


--- Quote from: Marsupial on September 22, 2010, 12:04:02 pm ---The main issue with parallel arise with the number of I/O you want to use. A normal LPT port has 9 IO plus control signals. for a two player / six button control pannel with 2 starts and no admin buttons, you have 22 separate inputs, and therefore would require 3 LPT ports, or another type of parallel port (remember LPT isn't the only one out there.)
Or you go with multiplexing, but then you loose the whole authenticity point.

--- End quote ---

Just to be clear, the IO circuits on old-school arcade boards are effectively multiplexing the inputs in (usually) 8 at a time.  Multiple parallel ports would do the same thing.  Each group of 8 bits would hang off the data bus and be read at different addresses via the use of tri-state buffers gated by the the decoded low order address bits (74244 or similar gated by a 74138 or similar).  Using several parallel ports just causes the sets of data (still only up to 8 at a time - the data lines and status lines are in separate 8-bit registers).  Adding an external mux driven off the parallel port control lines or using a register system is really no different than how authentic hardware did it.  You still have full control over exactly when everything is sampled.

USB HID does lack this control, but a non-HID device could give it to you still via USB.  HID is used because it's "good enough" (the polling rate can be set sufficiently high that data is always "fresh" whenever the application IO event loop wants it) and because it doesn't require drivers.

As to speed, the PC parallel port on a short, high quality cable (IEEE1284 defines some of those requirements) can achieve about 20-30Mbps in ECP DMA mode.  That is faster than Full Speed USB, but it's of course nowhere near High Speed USB.  ECP DMA mode is also pretty darned complicated and rarely used by anything other than printers and scanners that are pretty "smart" on their own.  EPP mode with 32-bit transfers (sometimes supported) can achieve about 5-10Mbps.  EPP mode is pretty easy to handle hardware wise, but none of these simple circuits will support it (not that they need to!).  Software handshaking is generally limited to about 1-2Mbps or even slower.  There's a limit to how fast the ISA (or LPC) bus can be cycled, and it's a lot slower than your CPU clock.

As to when USB HID devices actually check their button states, there's a couple options.  One is to just poll the buttons every time an IN token arrives (which is the poll rate for the endpoint).  I've done this for quick and dirty stuff, and it works quite well.  The other is to use a pin-change interrupt to update the report and send when the next IN is received if there has been a change.  A timer can also be used to update the report for the next send, but this is asynchronous to everything, and I wouldn't usually recommend it.  Either way, the maximum latency from input even to host notification is (1/f - epsilon) where f is the poll rate and epsilon is a small number (your input change JUST missed the previous poll).  If you make f high enough that (1/f - epsilon) is less than the time it takes the application's event loop to cycle, you've always got fresh data for the event loop.  One can argue that care needs to be taken to "latch" input changes until they are "consumed", but nobody's capable of hitting a button for 1/125th of a second, so it's not generally necessary.

JustMichael:


--- Quote ---
--- Quote from: JustMichael ---The default polling rate for a USB HID device is 125 times per second.  How many keys or inputs is that?  Depends upon the device.  Considering the size of a block of data from a USB device, it could be HUNDREDS of keys sent all at the same time 125 times per second.  Which means HUNDREDS of keys sent all at once 2 times per game frame.  Using the information AndyWarne provided earlier, all of the I-PAC inputs are sent all at the same time 8 times per game frame.

--- End quote ---

Not with keyboard controller, no. You can not send "all at the same time" via serial line, nor you can stuff them in the keyboard buffer all at once, nor you can generate them all in the same time. -- Where do you pull those numbers from anyway?

--- End quote ---

I believe normal USB keyboards are limited to reporting up to 6 keys at once.  As to why that limit is imposed, I have no idea.  They could easily send many more keys than that at once.  The I-PAC and other devices like it don't suffer from this limit.  This is just one of many reason people like those devices for arcade cabinets.  Yes, USB data is sent 1 bit at a time but it is sent so fast that all the data is received and processed in much less time than 125/second polling rate.  As for the 125 polling rate I got that straight from registry of my windows XP installation.


--- Quote ---
--- Quote ---Doesn't it seem bad to you to connect ground directly to power?

--- End quote ---

That's not really "ground". Pins 18-25 are real LPT ground. What I call "ground" are LPT-OUTPUT pins, and the 9 "data" lines go to LPT-INPUT pins.

--- End quote ---

When a pin is set to 0 that IS ground.  You are using pins 2, 3, 4 as outputs so they are either output a 1 (power) or a 0 (ground).  18-25 are just always ground (a 0).

Below is a picture of what I think you are trying to do.  This is a matrix.  To check the buttons, you set pins 3 and 4 high and pin 2 to ground and then check what is being pressed.  You then set pin 2 and 4 to high and set pin 3 to ground and then check what is being pressed.  You then set pins 2 and 3 to high and set pin 4 to ground and then check that is being pressed.  I put the diodes (blue) in to prevent shorting power to ground.  The problem with a matrix is ghosting.  For example if pin 2 is set to ground and the switches at (pin 1, pin 2) and (pin 1, pin 3) and (pin 17, pin 3) are being pressed, you will see a ghost keypress at (pin 17, pin 2).



MonMotha:


--- Quote from: JustMichael on September 22, 2010, 03:46:11 pm ---I believe normal USB keyboards are limited to reporting up to 6 keys at once.  As to why that limit is imposed, I have no idea.  They could easily send many more keys than that at once.  The I-PAC and other devices like it don't suffer from this limit.  This is just one of many reason people like those devices for arcade cabinets.  Yes, USB data is sent 1 bit at a time but it is sent so fast that all the data is received and processed in much less time than 125/second polling rate.  As for the 125 polling rate I got that straight from registry of my windows XP installation.

--- End quote ---

This is a limit of the "boot protocol" keyboard.  The "boot protocol" is a very stripped down version of HID that enables a simple USB host (e.g. the PC BIOS) to handle HID reports without actually having to parse the descriptor to understand the format since the format is fixed.  The number of simultaneous keypresses was arbitrarily chosen at 6.  For normal keyboard use, this is probably more than sufficient especially since modifier keys (shift, ctrl, etc.) are not included in this limitation.

It is possible to make a HID keyboard that supports both boot protocol mode and an extra mode that lifts the boot protocol limitations.  In theory, a smarter USB host (e.g. Windows) should switch the device into the higher capable mode.  I don't know that this happens correctly.

It's also possible to make a HID keyboard that just isn't boot protocol compatible at all (just declare your usage as a "keyboard" with an INPUT element having your choice of format).  It won't work in the BIOS, but a fully featured USB host (e.g. Windows, Linux, OSX, etc.) should handle it without issue, and the only limitations are what you (the device maker) define.  This is fine for things that aren't really keyboards.  This is probably what the IPAC and Keywiz type devices do.

JustMichael:

Thanks!!  I had no idea that was why the USB keyboards I have tried all have the same 6 key limit.   :applaud:

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

Go to full version