Main > Main Forum
USB vs PS/2 vs COM vs LPT
<< < (2/43) > >>
patrickl:
Yeah he's bound to come down hard on SavannahLion for claiming that PC's without a PS/2 port exist.
Driver-Man:

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

--- End quote ---

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.



--- Quote from: 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.

--- End quote ---

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



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

--- End quote ---

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.




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

--- End quote ---

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.



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

--- End quote ---

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.

--- End quote ---

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: ---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.
*/
--- End code ---




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

--- End quote ---

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



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

--- End quote ---

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:

--- Quote from: CheffoJeffo on September 20, 2010, 07:40:47 am ---* CheffoJeffo  really hopes that RandyT posts in this thread.
 :droid

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

Navigation
Message Index
Next page
Previous page

Go to full version