USB vs PS/2 vs COM vs LPT

[Driver-Man]

There is one thing about "Building Your Own Arcade Controls" that no one seem to realize, it also happens to be the most important thing of all - sampling rate in relation to multiple simultaneous input.


For some reason USB seem to be the most popular, which is a mistake, whether you are using keyboard hack, I-Pac or some USB joystick hack. USB, PS/2 and COM are serial communication ports, which means you can only send one bit at the time. It's further restricted with the operating frequency and slowed down by the processing and control bits overhead.


Originally arcade games read input in parallel, so the states of all the buttons is known instantaneously for every single frame of animation. If you press all the 12 buttons in Street Fighter and release them very next frame, after 1/60 of a second, the game engine would know. -- This you can hardly achieve with any of the serial ports as it takes time to communicate multiple simultaneous inputs, so the input info always comes later than it occurred and individual timings are uncertain.


Only LPT can communicate *instantaneous* state of the port at any given time and as often as the CPU clock ticks, 8 bits at the time, in parallel, which means you can read the state of 16 buttons in just two instructions. In contrast, the serial communication driver would need to perform at least about 8x16 = 128 instructions, plus the data encoding and buffer manipulation.


Now, there is also no point in using Genesis or PS2 joystick via parallel port if they themselves send information serially, which they do. In fact, of all the parallel ports drivers and joysticks there is only one you want to use - TurboGraFX or "tgxlpt1". http://www2.burg-halle.de/~schwenke/parport.html


Good news is MAME already supports this interface, even better news is that this just happens to be the CHEAPEST one you can build. You only need the wires to connect microswithes with your LPT port, that's all. In my experience you DO NOT even need any resistors or diodes.

[Osirus23]

Wow you're right, with a 2.0Ghz CPU those 16 buttons would take 0.000000064 seconds to process. Imagine the lag. I can't believe how foolish we've been all this time. 

[SavannahLion]

Well... you raise an interesting point there, however there are two things to consider.

The discussion really only applies to older computers. While I'm all for the preservation of older computers (My Atari XEGS can attest to that). The sad fact of the matter is most, of not all my PCs eventually get re-purposed for other uses until they're eventually retired (eg stored) serving no other purpose other than to fire up and test old software. I have not actually re-purposed any of my older PC's to play MAME exclusively (not yet anyways).

Which leads me to my next point. Personally, I haven't purchased a new PC or motherboard with any sort of RS232 or parallel port in roughly eight years or so. I haven't purchased a new PC with a PS/2 port in roughly five.

Believe me when I say this fact probably hurts me more than most. Not having a traditional serial or parallel port means I've had to find new programmers that support USB or make attempts at finding and or using less than ---smurfy--- USB<->serial cables. Not having PS/2 means I've had to make some minor adjustments to my all time favorite PS/2 based HIDs.

USB is the most popular because that is what dominates the peripheral interface. So, for most of us, the decision is already made.  

You raise an interesting point, but it is made moot by the decreasing presence of these ports.

Wow you're right, with a 2.0Ghz CPU those 16 buttons would take 0.000000064 seconds to process. Imagine the lag. I can't believe how foolish we've been all this time. 

Wouldn't any potential limitation not lie with the CPU but with the bus speed of USB? But yeah, that too. The difference in serial communication on a 2010 2.0 GHZ processor and parallel communication on a 18 year old computer running at 12MHz is pretty much negligible.

[JustMichael]

There is one thing about "Building Your Own Arcade Controls" that no one seem to realize, it also happens to be the most important thing of all - sampling rate in relation to multiple simultaneous input.


For some reason USB seem to be the most popular, which is a mistake, whether you are using keyboard hack, I-Pac or some USB joystick hack. USB, PS/2 and COM are serial communication ports, which means you can only send one bit at the time. It's further restricted with the operating frequency and slowed down by the processing and control bits overhead.

You seem to think transmitting data 1 bit at a time is a bad thing.  If you haven't noticed, hard drives have gone from parallel ATA to serial ATA.  They transmits the data 1 bit at a time.  They have smaller cables (due to fewer wires needed) and even more data comes through in the same amount of time.  Did you know that a lot of the "internet" is transmitted 1 bit at a time?  One pulse of laser light in that fiber optic at a time.  Just because a method transmits 1 bit at a time doesn't necessarily make it slower.

You do realize that the windows default polling rate for HID (Human Interface Device) USB devices is 125hz (125 times per second).  You said Mame looks for input 60 times per second.  Hmmm, looks like USB exceeds this.

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.

Just so you know, devices like the I-PAC read their inputs in parallel to avoid any possible ghosting and they even read their inputs more than 60 times a second.

So a USB device like an I-PAC will report what keys are being pressed 2 times for each time that Mame asks for inputs.  It looks like USB devices exceed what Mame needs.

Only LPT can communicate *instantaneous* state of the port at any given time and as often as the CPU clock ticks, 8 bits at the time, in parallel, which means you can read the state of 16 buttons in just two instructions.

Doesn't matter one bit (pun intended).  The state of the port only matters when you are looking at it.  If you look at it 60 times a second, its state only matters during those 60 times.  USB gets checked twice as often.

Good news is MAME already supports this interface, even better news is that this just happens to be the CHEAPEST one you can build.

You seemed to have forgotten to add in a very nasty cost. The cost of someone's "Time".  Simply put when you add in the time for us to search around to find out how to interface to the LPT port, time to decide what parts we will need and time to go and buy them and time to try to assemble the whole thing (even if we don't fry anything).  Now personally I would rather buy an I-PAC knowing that it will work and spend the few hours I saved having fun with my children.  Is the LPT interface cheaper?  IMHO, money-wise yes but overall no (especially if you fry something).

You only need the wires to connect microswithes with your LPT port, that's all. In my experience you DO NOT even need any resistors or diodes.

Highly depended upon manufacturer of the LPT port.  I would recommend sticking to whatever is the accepted method of interfacing to the LPT port and not using "just wires".

[CheffoJeffo]

* CheffoJeffo  really hopes that RandyT posts in this thread.

 

[patrickl]

Yeah he's bound to come down hard on SavannahLion for claiming that PC's without a PS/2 port exist.

[Driver-Man]

USB is the most popular because that is what dominates the peripheral interface. So, for most of us, the decision is already made.

Ok, and it is probably difficult to notice the difference with most of the games. However, with 2 player simultaneous games, especially those where timing is critical, such as Street Fighter series, this could make a difference between executing some combo easy and not being able to pull it off at all. -- Did I mention there need to be scan codes sent when key is both pressed and depressed, which makes it "double-trouble" for keyboard controllers, if that turns out to be the bottleneck.

You seem to think transmitting data 1 bit at a time is a bad thing.  If you haven't noticed, hard drives have gone from parallel ATA to serial ATA.  They transmits the data 1 bit at a time.  They have smaller cables (due to fewer wires needed) and even more data comes through in the same amount of time.  Did you know that a lot of the "internet" is transmitted 1 bit at a time?  One pulse of laser light in that fiber optic at a time.  Just because a method transmits 1 bit at a time doesn't necessarily make it slower.

Having the same frequency, 8 bits at the time is faster than 1 bit at the time. Serial communication is popular becasue it's cheaper (less wires) and we can even-up the difference by increasing the frequency. On the other hand, brain for example works in parallel which makes it possible to achieve high information bandwidth while still operating at low frequency ~500Hz (mine works @ 1000Hz.... but it's overheating often, heh). It's not about good and bad, just better or worse for some given application, were "worse" might just as well be "good enough".

You do realize that the windows default polling rate for HID (Human Interface Device) USB devices is 125hz (125 times per second).  You said Mame looks for input 60 times per second.  Hmmm, looks like USB exceeds this.

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.

Yes, that's one part of it. But, it's not about USB speed at all, it's about controller clock frequency and computer sampling rate of the port, as you said. USB is fast, for the sake of simplicity we can even say the transmission is instantaneous, this is not what matters much and I am not talking about it at all.

If animation is at 60FPS, then 720 bytes per second would give us 12 scan codes per frame, which can be less than 12 inputs as some keys, such as 'arrow keys', use two scan codes, and what is worse there needs to be a delay between each code... but, again, this is not the real bottleneck here.


The bottleneck is 125Hz (windows default polling rate for HID), although I think it's 250Hz, with the possibility to go up to 1000Hz, but I find it hard to Google a good source for these numbers and confirm it. Anyway, if animation is at 60FPS, then 125Hz would give us only 2 scan codes per frame, which is only one input if the key you pressed was arrow key.

Just so you know, devices like the I-PAC read their inputs in parallel to avoid any possible ghosting and they even read their inputs more than 60 times a second.

So a USB device like an I-PAC will report what keys are being pressed 2 times for each time that Mame asks for inputs.  It looks like USB devices exceed what Mame needs.

There it is, the second part, another frequency that matters.

Now we have:

a.) controller clock frequency - rate (not speed) at which data is sent
b.) windows sampling frequency - rate at which data is read from the port


Do you say I-Pac can generate scan codes at maximum of 120Hz? If so, than that's your new bottleneck, but not much worse than 125Hz you said it's Windows default sampling rate of HID. Anyhow, if animation is at 60FPS, then 120Hz would again give us only 2 scan codes per frame, which is just one input if the key you pressed was arrow key.

  
PS1 controller port clock is at 250kHz, and PS2 at 500kHz, that's kilo hertz. I do not know at what rate PS1 and PS2 DualShock controllers can send the data, though I would certainly expect it to be above 900Hz.

Only LPT can communicate *instantaneous* state of the port at any given time and as often as the CPU clock ticks, 8 bits at the time, in parallel, which means you can read the state of 16 buttons in just two instructions.

Doesn't matter one bit (pun intended).  The state of the port only matters when you are looking at it.  If you look at it 60 times a second, its state only matters during those 60 times.  USB gets checked twice as often.

Of course it matters. Yes, I suppose you could say it only matters when you are looking at it, but that is exactly how you handle input, you look (read) the current state of input. Waiting for input to come is no good.


So, if USB gets checked 120 times per second, that will give us only 2 inputs per frame, which means that if you press DOWN+RIGHT, you will not be able to fire until the next frame. That sounds too bad, so I think we do not have correct numbers. Anyway, if you look at some older source of MAME you can see this:

Code: [Select]

input.c
/*
  since the keyboard controller is slow, it is not capable of reporting
  multiple key presses fast enough. We have to delay them in order not
  to lose special moves tied to simultaneous button presses.
*/

You seemed to have forgotten to add in a very nasty cost. The cost of someone's "Time".  Simply put when you add in the time for us to search around to find out how to interface to the LPT port, time to decide what parts we will need and time to go and buy them and time to try to assemble the whole thing (even if we don't fry anything).  Now personally I would rather buy an I-PAC knowing that it will work and spend the few hours I saved having fun with my children.  Is the LPT interface cheaper?  IMHO, money-wise yes but overall no (especially if you fry something).

It took me about 25 min to solder 11 wires, and that was it. I guarantee it will work. Do you think MAME would support it just like that? This very well tested and documented interface. I do not see how could you possibly fry anything, it's very low current and voltage on parallel port, plus all the pins are designed to carry it, you do not need any external source of power, or anything.


There is nothing to search for, here you have it all:
http://www2.burg-halle.de/~schwenke/parport.html

There is 9 data lines which you connect to one end of the microswitch (5 buttons + 4 directions), the other end of the microswitch you connect with "ground pin", just like with real arcade harness. The best part is that to add another joystick (9 more inputs) you only need to add one more ground wire, and that's all. There is maximum of 7 grounds, so maximum of 9x7 = 63 inputs.

I explained it here in more detail:
http://forum.arcadecontrols.com/index.php?topic=105222.0

Highly depended upon manufacturer of the LPT port.  I would recommend sticking to whatever is the accepted method of interfacing to the LPT port and not using "just wires".

I don't know what you mean. All the LPT ports simply must have these lines used in this interface, otherwise they would not work with printers either. -- I tested this on 5 computers, from old to new, including one laptop, it worked perfectly everywhere. -- Where is your sense of adventure? Where did your "Build Your Own" from "Build Your Own Arcade Controls" go?

[Hoopz]

* CheffoJeffo  really hopes that RandyT posts in this thread.

 

The last few threads that could have been WWIV and WWV between Andy and RandyT didn't develop.  Oh the glory days....

I'd be more interested to hear from Haze, Derrick Renaud, or u_rebelscum about this as they have the coding perspective from Mame and the technical expertise with USB, PS/2, etc.  (Not that Andy/RandyT don't have technical expertise with USB, PS/2, etc.  I'm just interested in the Mame points that the troll makes).

[saint]

If you're looking at this as an intellectual exercise, and enjoy doing your own hacking (yes, very much in the spirit of this hobby and forum I agree) then this is bound to be a good geeky/techie conversation. 

If you're trying to say that the various encoders and such being used these days are the wrong way to go from a practical perspective you're in for a losing battle. I'm not aware of any issues with current methods for interfacing arcade controls that suffer from lag or lost control movements due to hardware limitations. There may be technical bottlenecks, but the hardware and software are designed well enough and fast enough that the end user experience suffers no penalties.

Combine that with the decreasing availability of parallel and serial and even PS/2 ports (I'm seeing more and more computers with a single PS2 port instead of 2) and this discussion is very much an intellectual exercise, not a practical one.

I *like* the technical discussion, so don't think I'm trying to tell you not to waste your time. I'm saying there aren't likely to be any epiphanies leading to changes in the hobby. 

[severdhed]

what is the point of this discussion at all?  is there anyone here using a USB interface that has ever had lag problems with their controls?  I have been used several different USB interfaces and have never once noticed any kind of performance issue, even when using multiple usb interfaces simultaneously.

[newmanfamilyvlogs]

I'm saying there aren't likely to be any epiphanies leading to changes in the hobby. 

Just wait! The market for USB->Parallel adapters is going to explode!  (;

[ptinolv]

That may be a too simple way to see things, but almost every high level players play SFIV with a USB fighstick (ps3 or xbox). I have never heard anyone complain about the lag of the usb interface.

[eds1275]

In my experience with the different ports, USB is just easier. Honestly most of my audio equipment is firewire and I prefer that, but usb is great for this kind of thing - it usually just works, often without the hassle of installing drivers.

I have different experiences with the LPT port - more often than not, I have found that using this port causes major issues when hibernating the computer. With some of my gear, using this port prevents the computer to shut down or hibernate. With other gear, upon re-awakening the con nection is lost.

Not so much experience with the com port.

[Driver-Man]

what is the point of this discussion at all?  is there anyone here using a USB interface that has ever had lag problems with their controls?  I have been used several different USB interfaces and have never once noticed any kind of performance issue, even when using multiple usb interfaces simultaneously.

The point I am interested in is to find out the real numbers, the frequencies at which these ports and controllers operate, maybe that's all fine after all, I have no source to confirm either way and I'm lazy to test, but what I do know is that this interface simply can not have any of those problems, it's perfect!

The points you might be interested in, besides being cheap, fast and perfect, is that even though you may not notice.... if you fail to jump over barrel in Donkey Kong you would know it is only you to blame, and not Windows or some keyboard controller for reporting your jump one frame too late. In other words, it would make the game more "legitimate" and probably easier too. You would not want to be failing to break some high-score just because you can run the game at only 12 FPS, right? This would be almost exactly the same, just need to find out how bad or not bad it really is. -- Don't forget that USB can be set up to probably 1000Hz, so perhaps your friendly neighborhood Driver-Man can solve the problems if it turns out there are any. My name is not Driver-Man becasue I drive a truck, but becasue I make drivers.

[Osirus23]

A USB interface polls at about every 0.002 seconds. The screen (at 60Hz) refreshes every ~0.0167 seconds, with lower framerate games being a higher number yet. Anyone trying to excuse their gaming mistakes on an inferior interface is just kidding themselves.

[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

[KagatoAMV]

This thread reminds me of trying to get the bi-directional parallel ports working properly between some Compaq desktops and some R&D Equipment.

Driver-man, have you observed the problem you brought up in your earlier post when using keyboard emulator based controls? Or are you approaching this from the logic/mathematical point of view?

I'm curious if there is a practical difference in input methods, detectable by either the game emulator or the player. I suppose you could set up a double blind test... that's a fun experiment to consider. 

[JustMichael]

You seem to think transmitting data 1 bit at a time is a bad thing.  If you haven't noticed, hard drives have gone from parallel ATA to serial ATA.  They transmits the data 1 bit at a time.  They have smaller cables (due to fewer wires needed) and even more data comes through in the same amount of time.  Did you know that a lot of the "internet" is transmitted 1 bit at a time?  One pulse of laser light in that fiber optic at a time.  Just because a method transmits 1 bit at a time doesn't necessarily make it slower.

Having the same frequency, 8 bits at the time is faster than 1 bit at the time. Serial communication is popular becasue it's cheaper (less wires) and we can even-up the difference by increasing the frequency. On the other hand, brain for example works in parallel which makes it possible to achieve high information bandwidth while still operating at low frequency ~500Hz (mine works @ 1000Hz.... but it's overheating often, heh). It's not about good and bad, just better or worse for some given application, were "worse" might just as well be "good enough".

But the reality of the situation is they don't have the same frequency.  One of the big reasons of going to serial is that as the frequency gets higher a parallel system starts picking up interference even more and even interfering with itself.  Yes I am sure they could build parallel cables to do the job but in reality the cables would be extremely expensive.

You do realize that the windows default polling rate for HID (Human Interface Device) USB devices is 125hz (125 times per second).  You said Mame looks for input 60 times per second.  Hmmm, looks like USB exceeds this.

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.

Yes, that's one part of it. But, it's not about USB speed at all, it's about controller clock frequency and computer sampling rate of the port, as you said. USB is fast, for the sake of simplicity we can even say the transmission is instantaneous, this is not what matters much and I am not talking about it at all.

If animation is at 60FPS, then 720 bytes per second would give us 12 scan codes per frame, which can be less than 12 inputs as some keys, such as 'arrow keys', use two scan codes, and what is worse there needs to be a delay between each code... but, again, this is not the real bottleneck here.

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.

The bottleneck is 125Hz (windows default polling rate for HID), although I think it's 250Hz, with the possibility to go up to 1000Hz, but I find it hard to Google a good source for these numbers and confirm it. Anyway, if animation is at 60FPS, then 125Hz would give us only 2 scan codes per frame, which is only one input if the key you pressed was arrow key.

USB does not transmit just 1 key each time it is polled like you are trying to suggest.  The USB device transmits a block of data each time it is asked.  The computer takes the USB data and determines which keys are being press and tells Mame all the keys that are being pressed each time Mame asks.

Just so you know, devices like the I-PAC read their inputs in parallel to avoid any possible ghosting and they even read their inputs more than 60 times a second.

So a USB device like an I-PAC will report what keys are being pressed 2 times for each time that Mame asks for inputs.  It looks like USB devices exceed what Mame needs.

There it is, the second part, another frequency that matters.

Now we have:

a.) controller clock frequency - rate (not speed) at which data is sent
b.) windows sampling frequency - rate at which data is read from the port


Do you say I-Pac can generate scan codes at maximum of 120Hz? If so, than that's your new bottleneck, but not much worse than 125Hz you said it's Windows default sampling rate of HID. Anyhow, if animation is at 60FPS, then 120Hz would again give us only 2 scan codes per frame, which is just one input if the key you pressed was arrow key.

  
PS1 controller port clock is at 250kHz, and PS2 at 500kHz, that's kilo hertz. I do not know at what rate PS1 and PS2 DualShock controllers can send the data, though I would certainly expect it to be above 900Hz.

The I-PAC detects which keys are being pressed way way more that 120 times per second.  The I-PAC sends all the keys that are being pressed whenever windows asks.  The I-PAC does NOT send only 1 key each time windows asks it.  It sends all of them as a block of data.

Only LPT can communicate *instantaneous* state of the port at any given time and as often as the CPU clock ticks, 8 bits at the time, in parallel, which means you can read the state of 16 buttons in just two instructions.

Doesn't matter one bit (pun intended).  The state of the port only matters when you are looking at it.  If you look at it 60 times a second, its state only matters during those 60 times.  USB gets checked twice as often.

Of course it matters. Yes, I suppose you could say it only matters when you are looking at it, but that is exactly how you handle input, you look (read) the current state of input. Waiting for input to come is no good.


So, if USB gets checked 120 times per second, that will give us only 2 inputs per frame, which means that if you press DOWN+RIGHT, you will not be able to fire until the next frame. That sounds too bad, so I think we do not have correct numbers. Anyway, if you look at some older source of MAME you can see this:

Code: [Select]

input.c
/*
  since the keyboard controller is slow, it is not capable of reporting
  multiple key presses fast enough. We have to delay them in order not
  to lose special moves tied to simultaneous button presses.
*/

Again you seem to think USB devices sends only 1 key each time they are asked.  They don't.  USB devices send a block of data which will contain all the keys that are being pressed.

You seemed to have forgotten to add in a very nasty cost. The cost of someone's "Time".  Simply put when you add in the time for us to search around to find out how to interface to the LPT port, time to decide what parts we will need and time to go and buy them and time to try to assemble the whole thing (even if we don't fry anything).  Now personally I would rather buy an I-PAC knowing that it will work and spend the few hours I saved having fun with my children.  Is the LPT interface cheaper?  IMHO, money-wise yes but overall no (especially if you fry something).

It took me about 25 min to solder 11 wires, and that was it. I guarantee it will work. Do you think MAME would support it just like that? This very well tested and documented interface. I do not see how could you possibly fry anything, it's very low current and voltage on parallel port, plus all the pins are designed to carry it, you do not need any external source of power, or anything.


There is nothing to search for, here you have it all:
http://www2.burg-halle.de/~schwenke/parport.html

There is 9 data lines which you connect to one end of the microswitch (5 buttons + 4 directions), the other end of the microswitch you connect with "ground pin", just like with real arcade harness. The best part is that to add another joystick (9 more inputs) you only need to add one more ground wire, and that's all. There is maximum of 7 grounds, so maximum of 9x7 = 63 inputs.

I explained it here in more detail:
http://forum.arcadecontrols.com/index.php?topic=105222.0

Highly depended upon manufacturer of the LPT port.  I would recommend sticking to whatever is the accepted method of interfacing to the LPT port and not using "just wires".

I don't know what you mean. All the LPT ports simply must have these lines used in this interface, otherwise they would not work with printers either. -- I tested this on 5 computers, from old to new, including one laptop, it worked perfectly everywhere. -- Where is your sense of adventure? Where did your "Build Your Own" from "Build Your Own Arcade Controls" go?

The website you posted as an example shows a device with resistors and diodes but yet you say you don't need any of that stuff.  This makes my Rule #1 alarm bell go off.  Rule #1: Don't believe everything you read on the internet.  Sub-rule #1a:  Even if you are willing to believe what you read, take it with a block of salt.  Since you state something other than what your example shows I would have to check around and see what information I could come up with to confirm or deny your supposition.  Even if you stated the same thing as your example stated, I would still have to check around to determine the facts for myself before I risk my computer.  Before you say "What risk?  There is no risk!", about 5 years ago a friend of mine tried wiring a couple joysticks to his printer port.  He had me there to test them out with him.  When he powered on the pc, we heard a muffled pop and then smelled a funny smell (not funny in a good way either).  His machine never booted up.  I can only guess he miss wired something or the plans he followed were incorrect.  Either way, after that day I just leave well enough alone.

[RandyT]

In fact, of all the parallel ports drivers and joysticks there is only one you want to use - TurboGraFX or "tgxlpt1". http://www2.burg-halle.de/~schwenke/parport.html


Good news is MAME already supports this interface, even better news is that this just happens to be the CHEAPEST one you can build. You only need the wires to connect microswithes with your LPT port, that's all. In my experience you DO NOT even need any resistors or diodes.

Without the pull-up resistors, the method will not work at all on parallel ports where they weren't built in.  Some were, and some weren't.

Now consider the following, where the green dots are switch closures;




Without diodes, what do you think happens at junction [ACK, Data 0] ?  If you don't know, you have no place in this community to direct others as to what is and isn't the best way to interface their controls.

RandyT

[JustMichael]

In fact, of all the parallel ports drivers and joysticks there is only one you want to use - TurboGraFX or "tgxlpt1". http://www2.burg-halle.de/~schwenke/parport.html


Good news is MAME already supports this interface, even better news is that this just happens to be the CHEAPEST one you can build. You only need the wires to connect microswithes with your LPT port, that's all. In my experience you DO NOT even need any resistors or diodes.

Without the pull-up resistors, the method will not work at all on parallel ports where they weren't built in.  Some were, and some weren't.

Now consider the following, where the green dots are switch closures;




Without diodes, what do you think happens at junction [ACK, Data 0] ?  If you don't know, you have no place in this community to direct others as to what is and isn't the best way to interface their controls.

RandyT

Amen!

[AndyWarne]

USB does not transmit just 1 key each time it is polled like you are trying to suggest.  The USB device transmits a block of data each time it is asked.  The computer takes the USB data and determines which keys are being press and tells Mame all the keys that are being pressed each time Mame asks.

Spot on. Furthermore the I-PAC is polled at 500Hz . There is just no issue here.

The way in which all pressed keys are sent, in virtually no time (12 Mbps), as a packet, and processed as such on the PC is the closest you will get to a game board.

[mrtuesday42]

just my .02$

i dont understand enough of this at the low level to give a truly valid opinion, but as far as an outsider reading this guys first post/thread start it SCREAMED troll at me. just everything about it was troll and not an actual conversation starter on the topic. just my two cents though.

[Osirus23]

just my .02$

i dont understand enough of this at the low level to give a truly valid opinion, but as far as an outsider reading this guys first post/thread start it SCREAMED troll at me. just everything about it was troll and not an actual conversation starter on the topic. just my two cents though.

Same here, I'm used to seeing this kind of nonsense from countless troll posts at avsforum.

[Driver-Man]

The PS/2 keyboard port can operate at around 30,000 bits per second.

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.

PS/2 = 30,000 bits per second/11 = 45 inputs per frame @ 60 FPS

PS/2 turns out to be better than USB? That sounds reasonable from where I stand, but Wikipedia says PS/2 is at 10 to 16 kHz. -- Can you confirm whether is that supposed to mean 16,000 bits per second, bytes per second, or scan codes per second? -- According to Wikipedia numbers, I think that comes down to about 24 inputs per frame, which IS good.

So your scenarios just don't hold any water, and the "mario example" is just absurd.

Your conclusion is based on what numbers? I was talking about USB and numbers given by JustMichael. You did it for PS/2, and that was good, now do the same for USB if you want to be talking about the same thing as I was.

USB = ?? bits per second/11 = ?? inputs per frame @ 60 FPS

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.

What did you say? Kbd data is provided in parallel over USB?

If you were talking about LPT... the sequence is defined by animation frames, that's the resolution, and as long as you poll the state every frame you are not missing any information - the "sequence" does not exist in-between the frames, you read input all at once, and the sequence you get when you look at the collection of some of those frames. That is exactly what makes SIMULTANEOUS press of 12 buttons, during only one frame, possible.

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.

At what maximum rate KeyWiz generates key codes, again? Please express that in bits per second as you did for PS/2, or scan codes per second. -- Anyway, it seems the numbers for PS/2 and your KeyWiz pass the Driver-Man's test of excellence, congratulations. Although, I do not see why would you not start making 'txglpt' adapters as well.

And then there's compatibility.  If the game supports the interface, then great.  What if it doesn't?

What game? MAME/MESS supports this interface, which means almost every game you would ever wanna play on your arcade cabinet supports it.

Are you talking about DOS games? Driver-Man already made that:
http://forum.arcadecontrols.com/index.php?topic=105222.0

The drivers out there don't seem to be available for Windows 7, and work has been discontinued.

What drivers? I'm talking about MAME, what games are you talking about?

Are you saying MAME support for "tgxlpt1" does not work under Windows 7? I would not know anything about it, I do not use MAME version later than v.58, nor OS later than XP. -- If there are indeed no drivers then I'll write the driver, will you test it?

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....

Code: [Select]

  int port = 0x378;                                        // LPT1
   int i,j,k,l,m;
   outportb(port+2,0x04);                                   // 4 extra inputs
   outportb(port,0xFF);                                     // all out high
      m=0xFE;                                               // start with 1st js
      for (j=0;j<7;j++)                                     // js1-7
      {
         outportb (port,m);                                 // active js to low
         m<<=1;                                             // shift the low signal
         m=m | 0x1;
         k=inportb(port+1);
         l=inportb(port+2);
         if (!(k & 16))  printf("up ");                     // Select    B-4
         if (!(k & 32))  printf("down ");                   // PaperEnd  B5
         if (!(k & 64))  printf("left ");                   // -ACK      B6
         if ((k & 128))  printf("right ");                  // Busy      B7
         if (!(k & 8))   printf("F1 ");                     // -Error    B3
         if ((l & 2))    printf("F2 ");                     // -AutoFeed C1
         if (!(l & 4))   printf("F3 ");                     // -SelectIn C2
         if ((l & 8))    printf("F4 ");                     // Init      C3
         if ((l & 1))    printf("F5 ");                     // -Strobe   C0
      }

http://www2.burg-halle.de/~schwenke/parport.html


By the way I'm not that guy, I just found it while I was looking for the parallel interface that uses most arcade-like wiring and can support the most inputs. Tgxlpt sets the maximum number of inputs in MAME and in many other emulators that supports it. Anything that runs with Allegro library too. Anything on Linux as well.

... and can output keyboard events properly, even with the RAW input model, because this is what the keyboard devices do.

Why in the world would you want to output keyboard events? What games and emulators are you talking about? MAME/MESS already have the driver built-in, and the best part about it is that you can forget all the 'scan codes' crap. Funny thing though, I actually did that already for use with NO$CPC emulator for Amstrad CPC, which does not have txglpt1 support built it. You can find download links here: http://forum.arcadecontrols.com/index.php?topic=105222.0

[Driver-Man]

USB does not transmit just 1 key each time it is polled like you are trying to suggest.  The USB device transmits a block of data each time it is asked.  The computer takes the USB data and determines which keys are being press and tells Mame all the keys that are being pressed each time Mame asks.

Spot on. Furthermore the I-PAC is polled at 500Hz . There is just no issue here.

The way in which all pressed keys are sent, in virtually no time (12 Mbps), as a packet, and processed as such on the PC is the closest you will get to a game board.

You mean USB is polled at 500Hz. Do we have some reference to confirm that number?

I'm asking at what maximum rate can I-PAC *generate* scan codes, how many per second?

[Driver-Man]

Without the pull-up resistors, the method will not work at all on parallel ports where they weren't built in.  Some were, and some weren't.

I suppose all 5 of my computers had them built in.

How do you know about it? Can you back that up, would there be some article on the Internet about it?

Now consider the following, where the green dots are switch closures;

Without diodes, what do you think happens at junction [ACK, Data 0] ?  If you don't know, you have no place in this community to direct others as to what is and isn't the best way to interface their controls.

I said I tested this on 5 computers, pay attention.

And what if it is you "who does not know", my human friend?

I know exactly what happens, take a look at the driver source code.


------------
No place in community? ...Driver-Man, friend or foe?

[saint]

Without the pull-up resistors, the method will not work at all on parallel ports where they weren't built in.  Some were, and some weren't.

I suppose all 5 of my computers had them built in.

How do you know about it? Can you back that up, would there be some article on the Internet about it?

http://www.beyondlogic.org/parlcd/parlcd.htm

http://www.hmpg.net/pinewood/

http://hw-server.com/docs/scp_ecp.html

http://www.finitesite.com/d3jsys/

"Normally the Printer Card will have internal pull-up resistors, but as you would expect, not all will. Some may just have open collector outputs, while others may even have normal totem pole outputs. In order to make your device work correctly on as many Printer Ports as possible, you can use an external resistor as well. Should you already have an internal resistor, then it will act in Parallel with it, or if you have Totem pole outputs, the resistor will act as a load."
http://www.luberth.com/cstep/parallel.htm



- that was just a quick Google search, and not my area of expertise.

No place in community? ...Driver-Man, friend or foe?

Plenty of room for someone building a better mousetrap or pushing the envelope of the hobby. Not so much room for confrontational attitudes You decide where you fit, I'd like to see where your contributions can take things -- mind the rules!

--- saint

[RandyT]

I said I tested this on 5 computers, pay attention.

And what if it is you "who does not know", my human friend?

I know exactly what happens, take a look at the driver source code.

Apparently you don't, and have proven my point.  It seems I gave you more of my time than I should have.  You'll have to get someone else to pay attention to you from here on out.

RandyT

[Driver-Man]

Apparently you don't, and have proven my point.

I suppose this is your point:
- "Without diodes, what do you think happens at junction [ACK, Data 0] ?"

Whatever you imagined happens, it does not happen. Can you now actually say what in the world were you hinting at? This is not some "keyboard matrix", there is no 'ghosting', or whatever is it you're being mysterious about.


As I said, what happens is described in the source code (above).... there is a loop that sends signal to each separate "ground wire" for joysticks 1 to 7, in sequence. Inside that loop you simply check if the signal has passed through any of the 9 data lines, and whichever line is set it means the microswitch circuit was closed, that's all. -- "Ground wires" are completely separate between 7 joysticks, while data lines can be shared between them all. This is completely opposite to JAMMA loom, but actual wiring is almost the same, and this is actually simpler (less wires). It's perfect.


=============
USB = ?? bits per second/11 = ?? inputs per frame @ 60 FPS

[RandyT]

Whatever you imagined happens, it does not happen. Can you now actually say what in the world were you hinting at? This is not some "keyboard matrix", there is no 'ghosting', or whatever is it you're being mysterious about.

Try again.

[AndyWarne]

USB does not transmit just 1 key each time it is polled like you are trying to suggest.  The USB device transmits a block of data each time it is asked.  The computer takes the USB data and determines which keys are being press and tells Mame all the keys that are being pressed each time Mame asks.

Spot on. Furthermore the I-PAC is polled at 500Hz . There is just no issue here.

The way in which all pressed keys are sent, in virtually no time (12 Mbps), as a packet, and processed as such on the PC is the closest you will get to a game board.

You mean USB is polled at 500Hz. Do we have some reference to confirm that number?

I'm asking at what maximum rate can I-PAC *generate* scan codes, how many per second?

OK here is a USB bus analyzer trace. This is the result of pressing 5 keys at the same time. Note the 2ms time intervals, and the fact all pressed keys (5 keys) are sent together.

[AndyWarne]

what is the point of this discussion at all?  is there anyone here using a USB interface that has ever had lag problems with their controls?  I have been used several different USB interfaces and have never once noticed any kind of performance issue, even when using multiple usb interfaces simultaneously.

The point I am interested in is to find out the real numbers, the frequencies at which these ports and controllers operate, maybe that's all fine after all, I have no source to confirm either way and I'm lazy to test, but what I do know is that this interface simply can not have any of those problems, it's perfect!

The points you might be interested in, besides being cheap, fast and perfect, is that even though you may not notice.... if you fail to jump over barrel in Donkey Kong you would know it is only you to blame, and not Windows or some keyboard controller for reporting your jump one frame too late. In other words, it would make the game more "legitimate" and probably easier too. You would not want to be failing to break some high-score just because you can run the game at only 12 FPS, right? This would be almost exactly the same, just need to find out how bad or not bad it really is. -- Don't forget that USB can be set up to probably 1000Hz, so perhaps your friendly neighborhood Driver-Man can solve the problems if it turns out there are any. My name is not Driver-Man becasue I drive a truck, but becasue I make drivers.

Another factor is unpredictable delays caused by sharing of interrupts. The parallel ports interrupts are shared with other items such as sound card, network card etc. The PS/2 port on modern motherboards is shared with the ACPI interface but I would suspect the effect of that share is far less than a network or sound card.

[CheffoJeffo]

I know exactly what happens, take a look at the driver source code.

This is one of the reasons that you are seen by many to be a troll ... you evade even the most obvious and direct questions.

Why don't you post what happens ?

Answer the question, Claire!

[SavannahLion]

Is it fair to point out, once again, that arguing about the parallel port and its "superiority" over the USB or even the PS/2 port is a moot point?

USB is the most popular because that is what dominates the peripheral interface. So, for most of us, the decision is already made.

Ok, and it is probably difficult to notice the difference with most of the games. However, with 2 player simultaneous games, especially those where timing is critical, such as Street Fighter series, this could make a difference between executing some combo easy and not being able to pull it off at all. -- Did I mention there need to be scan codes sent when key is both pressed and depressed, which makes it "double-trouble" for keyboard controllers, if that turns out to be the bottleneck.

You have completely missed the point there. For many the decision has already been made. No parallel port, period.

Yeah he's bound to come down hard on SavannahLion for claiming that PC's without a PS/2 port exist.

Then he's more than welcome to take a look at mine.

[Driver-Man]

Another factor is unpredictable delays caused by sharing of interrupts.

No interrupts here, you can handle LPT directly whenever your please and as often as your CPU can tick. You can also read the state repeatedly while waiting for vertical retrace.

If you are talking about the driver that would output keystrokes, for use with say DOS games, then you simply stick the routine to the timer interrupt. This is how I made my DOS TSR, and good thing about it is that you can program the timer and set whatever resolution (frequency) you want.

This is one of the reasons that you are seen by many to be a troll ... you evade even the most obvious and direct questions.

Why don't you post what happens ?

That was not direct question, but rhetoric question with wrong assumption, like asking: "Does your mother know you're gay?", having that you're actually not.  Anyway, I did explain what really happens, here it is again... there is a loop that sends signal to each separate "ground wire" for joysticks 1 to 7, in sequence. Inside that loop you simply check if the signal has passed through any of the 9 data lines, and whichever line is set it means the microswitch circuit was closed, that's all.


Can you define "troll" in relation to my "evil intentions"? What is it do you think I am doing? Is there anything I want or need from anyone here? Am I trying to sell you anything, or take anything from you? You think I want you to fry your computer?


All I am asking is to establish the numbers, actual HARDWARE SPECIFICATION, so anyone who wants can make their conclusions for themselves. I do also offer to explain what those numbers mean and what kind of impact they can have on game play. Then I offer to fix the problems if it turns out default numbers are too low. I also told you about the perfect interface, and I am not asking for anything in return... I'm your friend, sober up!

Is it fair to point out, once again, that arguing about the parallel port and its "superiority" over the USB or even the PS/2 port is a moot point?

Playing game = "controlling your game character". Is there anything more important about playing a game than playing a game?  -- It is equally bad running game below 100% and not being able to report all the input for every frame. In both cases your ability to "control" has decreased resolution and can have dire consequences on the game play, it makes the game harder and less authentic.

You have completely missed the point there. For many the decision has already been made. No parallel port, period.

You could just as well say your PC came with LCD monitor so the decision was made and you MUST use it. Do what you please and let others think and choose for themselves. Perhaps it wouldn't be unwise if you at least realize PS/2 is actually better than USB, eh?


I expected people here would be perfectionist in relation to their hardware and all the aspects of emulation, just as is MAME aspiration, but if two keys per frame is "good enough" for you, then cool... enjoy!

[RandyT]

All I am asking is to establish the numbers, actual HARDWARE SPECIFICATION, so anyone who wants can make their conclusions for themselves. I do also offer to explain what those numbers mean and what kind of impact they can have on game play. Then I offer to fix the problems if it turns out default numbers are too low. I also told you about the perfect interface, and I am not asking for anything in return... I'm your friend, sober up!

If you want to "fix" the issue I showed you, you can't do it in software.  You need to use those diodes.  There's a reason they are there, and the mere fact that you don't understand what that reason is, doesn't negate their necessity.  What you are telling people is wrong, and that means you really aren't being their "friend".  Just the opposite, in fact.

If you want to be a "friend" to the community, make a balls level driver for Windows 2K/XP/7 that will take gamepad, LPT, semifore, morse code, whatever, and allow one to map either gamepad or keyboard characters to it and make it work under everything, regardless as to whether the input scheme is DirectInput or RAW.  I doubt you are up to the task, but it's worth a shot.  Otherwise, you are offering pretty much nothing other than other peoples ideas (and ruining them, by making your own changes) and attempting to call into doubt long tried and tested methodologies.

Meh.
 
RandyT