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

[CheffoJeffo]

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.

Dealing with you is like dealing with an autistic child ... you could be an asset to the community if you could only communicate.

To be fair, this is somewhat like dealing with kowal, who doesn't speak English and says that he is dyslexic ... except that he gives us enough information to see that he isn't full of ---steaming pile of meadow muffin---.

I would have been be curious to see, as Hoopz mentions above, what the MAMEDevs think of your suggestions, but they've already tagged you as a troll, so no joy there.

For the record, I am not discouraging people from using LPT for the sake of a more authentic experience (after all, I dropped emulation entirely for the same experience), I am just wondering what you really bring to the party.

Your discussion of wiring is vague at best and having a single ground for a single player (which you seem to imply) is no defense against ghosting or blocking, so near as I can tell with just a quick look (it's time for YOU to actually do the work).

WARNING! SPECIFIC QUESTION: Why do the plans that you refer to include diodes ? I've never, working on vids, pins and computers, come across a situation where I just randomly thought that "I want to put some diodes here". It is puzzling that the guy who actually did the work thinks one way and you, who offer no proof but your "I tested this on 5 computers, pay attention" thinks the other ? I know that the lack of diodes isn't likely to kill a computer, but that's because I know what they are for and what they do. So, tell us, Driver-Man, why do the plans call for diodes and you say they aren't required ?

Is that specific enough for you ?

PS -- Does your mother know that you are a troll ?

[BobA]

Why does it always come back to the same thing?

[DJ_Izumi]

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.

No you wouldn't.  Because you are still EMULATING the original hardware and that will always add some form of additional lag from input to response just due to additional time needed to not only do the math in the game but do the emulation to give it the input and to spit out the response.

If you want 'The 100% real experience with no differences', go buy the real hardware.

[Driver-Man]

-If you want to "fix" the issue I showed you, you can't do it in software.

What issue? Are you talking about USB or LPT?

There are no issues with 'tgxlpt' interface.

You need to use those diodes.

I sure see your made yourself believe that, even though you have no idea how this interface actually works nor you have ever tried it, fascinating. -- I explained how it works, what part do you not understand?

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. 

The reason you can not name, the reason you forgot to tell us about, again.

What reason, what do you think happens without diodes, will you say it finally?

What you are telling people is wrong, and that means you really aren't being their "friend".  Just the opposite, in fact.

Ok, then you tell them about default polling rate of USB and how many inputs per frame that is, just like you did for PS/2:

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

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

This is like 8 years old interface. There are drivers for it included even in Linux kernel. All you want is already out there, except perhaps morse code... awww. -- I already responded to your previous challenge and provided drivers and source code you requested, now it's your turn to answer my questions, see above.

[JustMichael]

Driver-Man,
How about providing us with a schematic of your circuit and a schematic of your 27 input one?  This would be enough for 2 players (1 joystick and 8 buttons (start, coin and 6 player buttons each).

[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?

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!

Here, we have an illustrated example of just how astonishingly inattentive you really are. I would normally take Saint's information about you to heart, but at this point anybody in their right mine would question even that.

I'm not arguing the merits of parallel vs PS/2 vs USB. I'm saying it's a moot point because PC's are being sold without parallel ports. Period. End of discussion. It's like arguing Beta vs VHS vs DVD.

Your pathetic example of CRT vs LCD will have no merit in about ten years when no one manufactures CRT monitors.

Is this a concept that's too difficult for you to understand?

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

This is like 8 years old interface......

I know you're not actually going to read this, so this is for the benefit of our other readers who might follow your ill-informed information. The LPT or IEEE1324 was standardized sometime in 1994. As of this writing, that would be 16 years ago. The "standard" was actually in use before then, introduced sometime in the 1970's. Atari ST, released in 1985, sported said port and actually made use of it as a game controller port. picture of the Atari ST ports.

As I have once said, Driver raises an interesting point. However, it's a little late in the game. Parallel ports are gone from all but the most well equipped professional computers and PS/2 is on its way out. USB is here and, once again, the choice for many of us is already made.

Once Driver get his head out of his ass and start acting less like a troll, he might actually start having some decent conversations.

[SavannahLion]

Weird, it cut off the last bit in the edit... oh well.

LPT vs PS/2 vs USB would be an interesting discussion if it was academic. But that's about all it is in my book. As far as I'm concerned, use of the printer port is relegated to the "archives" section. Right alongside Dictabelt, U-matic, Reel-to-reel and that mysterious damn port on the back of my twenty year old Sears monitor, to be called upon if I should ever have the need to make use of it.

[RandyT]

There are no issues with 'tgxlpt' interface.

I don't disagree, as far as functionality is concerned.  It's just your "diode-less" implementation that has issues.

What reason, what do you think happens without diodes, will you say it finally?

No, it's a puzzle just for you.  When you solve it, you can move on to bigger things.  But I'll give you a hint: It's just about the first thing you would have learned about interfacing controls, had you taken the time to try before coming into this forum telling everyone they have been "doing it wrong", albeit very successfully, for the last 10 years.

But if you ask nicely, just about anyone who has been doing this for a while can tell you as well.  In fact, at least one of them already did.

RandyT

[Driver-Man]

Your discussion of wiring is vague at best and having a single ground for a single player (which you seem to imply) is no defense against ghosting or blocking, so near as I can tell with just a quick look (it's time for YOU to actually do the work).

1.) There is a loop that sends signal to each separate "ground wire" for joysticks 1 to 7, in sequence.

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

What part would you like me to explain? What is vague? Why do you think there would be ghosting or blocking?

Why do the plans that you refer to include diodes?

I do not know. Let's write him an e-mail and invite him here to explain? Meanwhile give him a break, not everyone is physicist and electrical engineer like your friendly neighborhood Driver-Man. Which reminds me, have I ever told you about that time when I was bitten by radioactive driver?

I've never, working on vids, pins and computers, come across a situation where I just randomly thought that "I want to put some diodes here". It is puzzling that the guy who actually did the work thinks one way and you, who offer no proof but your "I tested this on 5 computers, pay attention" thinks the other ?

Yes, I agree with your reasoning.

What can I tell you? The proof is in the pudding.

I know that the lack of diodes isn't likely to kill a computer, but that's because I know what they are for and what they do. So, tell us, Driver-Man, why do the plans call for diodes and you say they aren't required ?

"Plans" do not call for diodes at all, driver is what defines the hardware requirements. As you said, lack of diodes can not damage the computer, so just try it, see for yourself.

How about providing us with a schematic of your circuit and a schematic of your 27 input one?  This would be enough for 2 players (1 joystick and 8 buttons (start, coin and 6 player buttons each).

Code: [Select]


     |----[/]........................ pin 10 (left)
     |----[/]........................ pin 11 (right)
     |----[/]........................ pin 12 (down)
     |----[/]........................ pin 13 (up)
     |----[/]........................ pin 15 (F1)
     |----[/]........................ pin 14 (F2)
     |----[/]........................ pin 16 (F3)
     |----[/]........................ pin 17 (F4)
     |----[/]........................ pin  1 (F5)
     | | |
     | | |                                               
     | | |--------------------------- pin 2 (ground 1)
     | |                                                     
     | |----------------------------- pin 3 (ground 2)
     |                                                 
     |------------------------------- pin 4 (ground 3)
                                                    
                                                       

That above is not quite correct, it would be messy to draw it all, but is informative anyway.

This is how you wire separate joysticks, this part is what is missing in the diagram above:

Code: [Select]


     |---[/]........................ pin 10 (left)
     |                 .
     |---[/]........................ pin 11 (right)
     |             .   .
     |  |---[/].....   .                
     |  |              .
     |  |---[/].........  
     |  |
     |  |
     |  |                                              
     |  ------------------------------ pin 3 (ground 2)
     |
     |-------------------------------- pin 2 (ground 1)



[Driver-Man]

No, it's a puzzle just for you.  When you solve it, you can move on to bigger things.  But I'll give you a hint: It's just about the first thing you would have learned about interfacing controls, had you taken the time to try before coming into this forum telling everyone they have been "doing it wrong", albeit very successfully, for the last 10 years.

But if you ask nicely, just about anyone who has been doing this for a while can tell you as well.  In fact, at least one of them already did.

No answer? More mystery? Puzzle games?

Ok, that's cool, but this question you did not even see:

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

[JustMichael]

No, it's a puzzle just for you.  When you solve it, you can move on to bigger things.  But I'll give you a hint: It's just about the first thing you would have learned about interfacing controls, had you taken the time to try before coming into this forum telling everyone they have been "doing it wrong", albeit very successfully, for the last 10 years.

But if you ask nicely, just about anyone who has been doing this for a while can tell you as well.  In fact, at least one of them already did.

No answer? More mystery? Puzzle games?

Ok, that's cool, but this question you did not even see:

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

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.

Judging from your schematic Pins 2, 3, and 4 will either be set low (ground) or high (power).  I am guessing you will always have one pin set low and the other two set high to "rotate" the ground.  Doesn't it seem bad to you to connect ground directly to power?  VERY depended upon the chip(s), a grounded output can pull the high outputs down too.  This will SEVERELY shorten the life of the chip(s).  I wouldn't be surprised at all if on some computers it would release the magic smoke.  What you need is 3 diodes. One on each of your ground lines before they are tied together.  Placed properly, these diodes will prevent ground from being tied directly to power.

[Rick]

I'm actually quite surprised of the number of Experts here actually giving the OP the time of day.  Don't get me wrong.  I'm not the guy who's coming in to say he's wrong.  Oh, no.  Actually, his idea might be much better than the current standard, but hey, I honestly have no idea.  What I do note, as have many others, is the delivery of his message.  From the word go, it's basically been a slap in the face to everybody who's done it their way for years.  It's the "my way is right and your way is wrong" attitude that really isn't helping, and really isn't appreciated in this community.  The OP might just be the Stephen Hawking of his time, but because of his choice of delivery, he's coming off like Glenn Beck.

This whole conversation reminds me of one thing, actually.  VCR's.  (Remember them?)  Yeah.  I picture the OP being Beta, and our friendly Experts being VHS.  Sure, his idea might be better, and work exponentially faster and with less error, but we all know who's winning the war in the end.

[newmanfamilyvlogs]

Perhaps tangentially on topic:
I found this controller card in a "Silverball 3" cabinet.  I can't find that particular model online, but here is a more modern iteration: http://www.tab.at/tab/en/Desktopdefault.aspx/tabid-63/33_read-23/

It's an ISA card in a beigebox PC that runs the actual game. The Actel chip is a FPGA.



Those array of SMD components along the edge connectors are marked A4 which according to this:
http://www.repairfaq.org/REPAIR/F_SMD_trans.html#SMDTRANS_008

Lists them as BAW62 / 1N4148 diodes.

Obviously this not a parallel port, however the implementation is obviously identical, it's just a question of buses.

Just thought it might be interesting to see how this is done in a commercial product..

edit: Here's as close as I could take a picture of the SMD components:
http://lh5.ggpht.com/_xyVxXgjibE0/TJn9puL1nVI/AAAAAAAABkc/CZHCcSmt7RE/s800/P1080172.JPG

[SavannahLion]

Judging from your schematic Pins 2, 3, and 4 will either be set low (ground) or high (power).  I am guessing you will always have one pin set low and the other two set high to "rotate" the ground.  Doesn't it seem bad to you to connect ground directly to power?  VERY depended upon the chip(s), a grounded output can pull the high outputs down too.  This will SEVERELY shorten the life of the chip(s).  I wouldn't be surprised at all if on some computers it would release the magic smoke.  What you need is 3 diodes. One on each of your ground lines before they are tied together.  Placed properly, these diodes will prevent ground from being tied directly to power.

This was the conclusion I drew about this too (Is this the Ack/D0 problem being referred to?). But if that's the case then the lauding Driver's been doing doesn't jibe. He still isn't receiving all of the data in parallel. It's still being polled and likely buffered (I dunno, I haven't had a chance to study his source code references). In that sense, it's not much better than serial. In one blinding swoop, Driver's argument just collapsed, diode or no diode.

[Driver-Man]

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?

It is mostly mathematical, but curiosity was triggered with something I observed...

In Crazy Kong, not Donkey Kong, there is a bug, a trick you can use to skip the first level quickly: - go all the way right to the first ladder and climb up. Tap the joystick to the right to get in position. To know you are good to go you will still see Mario's back but he would be half-way off the edge. If not, try again. Now, the "suicide jump", *TAP* joystick to the right AND jump in the same time, RIGHT+JUMP. If done correctly you will fall through the floor and in to the second level, with big bonus if you manage to do it quickly before any barrels come in a way.

That just did not work as I remember, and after that I noticed it is pretty hard to do "right+jump" or "left+jump", it seemed it works better if I first start to move and then quickly jump, which is not how I think it should be.

No you wouldn't.  Because you are still EMULATING the original hardware and that will always add some form of additional lag from input to response just due to additional time needed to not only do the math in the game but do the emulation to give it the input and to spit out the response.

I suppose there are ways to help the situation. Do you think MAME uses some of those hacks? Can you stand still then 'jump+right' in Crazy Kong easy?

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.

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?

Judging from your schematic Pins 2, 3, and 4 will either be set low (ground) or high (power).  I am guessing you will always have one pin set low and the other two set high to "rotate" the ground. 

Yes. 

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

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.

[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]

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.

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]

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.

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?

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.

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

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.

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]

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.

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.   

[Marsupial]

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.

regardless, the point is, even with parallel ports you don't get the "same result" as you have the emulation software doing the job of polling the buttons. But thanks for clarification; I haven't looked a lot on arcade PCBs.

[DJ_Izumi]

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

Cheap encoders on the keyboard.  I've seen some jam when you press more than three even.  Really depends on the quality of the keyboard encoder.  Of course obviously in most NORMAL cases a keyboard won't have you pressing more than 6 buttons ever.

[Driver-Man]

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

Yes, they are either 0 or 1. Active "ground" line is actually set to 1, but there is 'active low' and 'active high', for example bit 7 happens to show logic 0 where there actually is +5v at pin 11.

Below is a picture of what I think you are trying to do.  This is a matrix. 

Do you know better than me what I had for breakfast too?



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

Code: [Select]

     |---[/]........................ pin 10 (left)
     |             .     
     |---[/]........................ pin 11 (right)
     |             .   .
     |  |---[/].....   .               
     |  |              .
     |  |---[/]......... 
     |  |
     |  |
     |  |                                               
     |  ------------------------------ pin 3 (ground 2)
     |
     |-------------------------------- pin 2 (ground 1)

Matrix?

Do not try and bend the spoon. That's impossible. Instead... only try to realize the truth.
- I am not trying to do anything, I already did it. Wake up, Neo.

[RandyT]

[Driver-Man]

MonMotha,

I like your super-powers, most impressive. Do you know what is actual, or most likely, bottleneck in the whole story with USB and keyboard controller, and how many scan codes per second that comes down to? Do you know at what rate PS2 DualShock and clones can generate data, and if that thing is plugged via PC USB what would set the bottleneck then?

[Rick]

Can we please shut this down?  Tell me there's something in our rules about posting respectfully, because this is just sad.

[JustMichael]

Do you know better than me what I had for breakfast too?

I see you are making just as much sense as normal.

This is a different schematic than the one you did in ascii art form.  I based my drawing off of the ascii art one.  Also why do you insist on showing someone else's examples that have diodes when you say they are not needed?

Matrix?

Do not try and bend the spoon. That's impossible. Instead... only try to realize the truth.
- I am not trying to do anything, I already did it. Wake up, Neo.

Funny you should choose this partial quote.  We are all hoping that you will realize the truth.

Code: [Select]

     |---[/]........................ pin 10 (left)
     |             .     
     |---[/]........................ pin 11 (right)
     |             .   .
     |  |---[/].....   .               
     |  |              .
     |  |---[/]......... 
     |  |
     |  |
     |  |                                               
     |  ------------------------------ pin 3 (ground 2)
     |
     |-------------------------------- pin 2 (ground 1)


Even this little ascii art schemtic is a matrix.  And yes it can have ghost presses too.  I will show you how.  Let's have pin 2 be ground and pin 3 be high.  We will hold down both switches that are connecting pin 3 to pin 10 and 11. Ok now let's hold down the switch connecting pin 2 to pin 10.  Now comes the "magic"...
The red line shows the path ground will take.  Please notice how it goes to both inputs even though NO switch directly connects pin 2 to pin 11.

[MonMotha]

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

Cheap encoders on the keyboard.  I've seen some jam when you press more than three even.  Really depends on the quality of the keyboard encoder.  Of course obviously in most NORMAL cases a keyboard won't have you pressing more than 6 buttons ever.

Separate issue.

While the USB boot protocol standard limits the maximum number of simultaneous keypresses on a USB keyboard in boot protocol mode to 6, a specific keyboard may have additional limitations.  All keyboards use a matrix configuration since it drastically reduces the number of IOs required on the control chip.  This results in ambiguous situations when multiple keys are pressed (potentially any more than 2 with the likelihood of ambiguity increasing as more keys are pressed).  The USB HID standard requires that the keyboard report no keypresses and instead report "Rollover error" in the event an ambiguous condition or more than 6 pressed keys occurs.

Using discrete IOs for each input, rather than a matrix, will eliminate this ambiguous input problem, but it's cost prohibitive on PC keyboards with their 104+ keys.  The keyboard encoder devices sold for arcade and other general-purpose input interfacing DO use discrete inputs in most cases I've seen.

MonMotha,

I like your super-powers, most impressive. Do you know what is actual, or most likely, bottleneck in the whole story with USB and keyboard controller, and how many scan codes per second that comes down to? Do you know at what rate PS2 DualShock and clones can generate data, and if that thing is plugged via PC USB what would set the bottleneck then?

Please read the USB HID standard.  It details every little part of USB HID.  USB HID does not work the way you seem to think it does.  A USB HID device updates its ENTIRE STATE to the host every time it is polled; it does not attempt to send "just what changed" like a PS/2 keyboard does which makes "number of scancodes per second" an irrelevant statistic.  Incidentally, this is exactly what a DualShock does (and most other console game controllers, as well).

For a boot protocol keyboard, the format of the update limits the device to 6 simultaneously activated inputs, but non-boot protocol devices need not have this limitation.  It's actually possible to create a USB HID device that speaks a format very similar to that of a DualShock (to the extent that you could actually just dump the "data" section of a DualShock's communication into a USB packet with the appropriate headers!).

[severdhed]

i feel so stupid for reading this entire thread

[DaOld Man]

At the risk of getting stuck like a fly to a sticky fly strip:

If pin 2 is high and pin 3 is low, and you press two buttons at the same time, wont that connect pin 2 to pin 3, thus making a direct short on the parallel port?

Im not trying to claim to be an expert, but with the research Ive done on the parallel port, the output pins (2-9) are either high (+ 5 VDC), or low (ground).
And they are only good for a few milliamps, so it looks to me like you would short out the outputs and probably fry your board.

To quote Forrest Gump: "And thats all I got to say about that."

[JustMichael]

At the risk of getting stuck like a fly to a sticky fly strip:

If pin 2 is high and pin 3 is low, and you press two buttons at the same time, wont that connect pin 2 to pin 3, thus making a direct short on the parallel port?

Im not trying to claim to be an expert, but with the research Ive done on the parallel port, the output pins (2-9) are either high (+ 5 VDC), or low (ground).
And they are only good for a few milliamps, so it looks to me like you would short out the outputs and probably fry your board.

To quote Forrest Gump: "And thats all I got to say about that."

If the right buttons are pressed, you are correct.  I even tried telling Driver-Man that earlier in this thread:

Judging from your schematic Pins 2, 3, and 4 will either be set low (ground) or high (power).  I am guessing you will always have one pin set low and the other two set high to "rotate" the ground.  Doesn't it seem bad to you to connect ground directly to power?  VERY depended upon the chip(s), a grounded output can pull the high outputs down too.  This will SEVERELY shorten the life of the chip(s).  I wouldn't be surprised at all if on some computers it would release the magic smoke.  What you need is 3 diodes. One on each of your ground lines before they are tied together.  Placed properly, these diodes will prevent ground from being tied directly to power.

I even provided him with a picture of his 9x3 matrix with diodes that would avoid shorting power to ground.

For those that have have suffered through this thread this far please queue the "beating a dead horse" and the "dumber than a box of rocks" jokes...
Also does anyone know where to buy a "clue" and how much shipping would be?  After all this I think someone needs one badly and it is not DaOld Man.

[Driver-Man]

Even this little ascii art schemtic is a matrix.  And yes it can have ghost presses too.  I will show you how.  Let's have pin 2 be ground and pin 3 be high.  We will hold down both switches that are connecting pin 3 to pin 10 and 11. Ok now let's hold down the switch connecting pin 2 to pin 10.  Now comes the "magic"... The red line shows the path ground will take.  Please notice how it goes to both inputs even though NO switch directly connects pin 2 to pin 11.

Yes, you are right, Driver-Man realizes the truth. Very good, magic and all, I appreciate that. It's actually inverse situation and instead of ghosting it's blocking. So, when player 2 holds Button A, it will not register when player 1 hits that same Button A. -- Thank you again, and can we settle now that for only one joystick we do not need diodes?

For those that have have suffered through this thread this far please queue

Do you realize MonMotha above confirmed most of what I was saying all along? Except diodes, you got that, you win, but that was beside the main point, my joystick really works, I did not lie to you, I just never got to wire both of them and realize the issue.

Please read the USB HID standard.  It details every little part of USB HID.

Thank you.

A USB HID device updates its ENTIRE STATE to the host every time it is polled; it does not attempt to send "just what changed" like a PS/2 keyboard does which makes "number of scancodes per second" an irrelevant statistic.

And what is the "host", where is the keyboard controller and keyboard buffer in your story?

Where is the keyboard interrupt and how all that plays out with USB polling rate and scan codes buffering? Also, of what use is the ability to update entire state if you can not GENERATE that information in necessary time-window...

Q.) If clock at that USB devices ticks at 120Hz, as JustMichael said, then it means it can only generate maximum of 120 bits per second, or bytes per second, or scan codes per second?

For a boot protocol keyboard, the format of the update limits the device to 6 simultaneously activated inputs, but non-boot protocol devices need not have this limitation.  It's actually possible to create a USB HID device that speaks a format very similar to that of a DualShock (to the extent that you could actually just dump the "data" section of a DualShock's communication into a USB packet with the appropriate headers!).

Is there default polling rate for USB joysticks, or would that all be the same as with keyboard and mouse? Does that depend on manufacturers, maybe drivers, or "windows setting"?

[MonMotha]

A USB HID device updates its ENTIRE STATE to the host every time it is polled; it does not attempt to send "just what changed" like a PS/2 keyboard does which makes "number of scancodes per second" an irrelevant statistic.

And what is the "host", where is the keyboard controller and keyboard buffer in your story?

"Host" in USB terminology refers to "whatever is upstream on the cable" including all hardware and software.  In other words, it's the USB root hub and host controller, and the software stack in your OS.

Where is the keyboard interrupt and how all that plays out with USB polling rate and scan codes buffering? Also, of what use is the ability to update entire state if you can not GENERATE that information in necessary time-window...

Q.) If clock at that USB devices ticks at 120Hz, as JustMichael said, then it means it can only generate maximum of 120 bits per second, or bytes per second, or scan codes per second?

There is no keyboard interrupt.  USB doesn't have "true" interrupts in the sense of directly allowing a connected device to assert an IRQ to the CPU.  An interrupt endpoint on a USB device is polled (using reserved time on the bus) at a specific rate.  This polling rate is set sufficiently high (for whatever application) that data being present on this endpoint and subsequently transferred to the host is essentially asynchronous to everything else going on hence functioning like an interrupt.  On USB, the host controls everything.  A device is not allowed to speak without the host giving its OK (by issuing an IN token).  The interrupt endpoint poll rate ensures that these IN tokens are issued often enough that delay between them is inconsequential.

The host is also allowed to poll the HID device "whenever it darn well feels like it" over the control endpoint, but this is not done in normal operation.

Note that PCIe and newer PCI devices use a similar interrupt mechanism.  Look up "message signaled interrupts" or MSI.

The USB bit clock is NOT 120Hz.  IN tokens are issued to the interrupt endpoint at 120Hz (or whatever).  The bit clock is 12MHz for full speed or 1.5MHz for low speed.  This means that 12 million bits (1.5 megabytes) can be moved on the bus every second on a full speed bus.  There's a fair bit of overhead, but that still leaves plenty of room to update HID type devices even at low speed.  Most consumer mice and keyboards are low speed.

Since scancodes are one byte on USB, that means that a full speed USB device could transfer 1.5 million scancodes every second, though that's not really how it works.  Every time the interrupt endpoint is polled by the host, the HID device sends its full status in the form of a "report".

For "array" format reports (used by most keyboards), there are a fixed number of "positions" in which scancodes can be placed.  If there are fewer keys pressed than this number of positions, unused positions are marked unused.  If more keys are pressed, a "Rollover Error" is indicated.  If the interrupt endpoint is polled at 120Hz by the host, this would limit the maximum size of the array (and hence number of simultaneously pressed keys) to an unnecessarily (heck, unreasonably) large 12,500 (minus a fair bit for overhead, but you get the idea of the magnitude of the numbers) if you were willing to take up all the bandwidth on the bus.

"Variable" format reports instead use a single bit associated with a specific scancode for each possible key, button, etc.  This means that there is no simultaneous key limitation for this format.  This is how most arcade keyboard encoders work.  In this case, one could report up to 100,000 inputs (again, minus a fair bit for overhead, but I'll ignore that here since it's still an huge number) 120 times per second.  Clearly, data rate is not the limiting factor.

The USB specification is very clear on all this, though I'll admit it's not the best written standard I've read.  You should read the specification before making technical arguments surrounding it.  You have some major misconceptions about how USB works.

Is there default polling rate for USB joysticks, or would that all be the same as with keyboard and mouse? Does that depend on manufacturers, maybe drivers, or "windows setting"?

For low speed devices, Windows uses the same polling rate for all HID devices (keyboards, mice, joysticks, gamepads, "vendor specific" devices, etc.) as far as I know, and that rate is (I think) 125Hz.  For full speed devices and other OSes, the polling rate specified by the device is used.  The device can pick pretty much whatever it wants, but 60-240Hz is common.

[RandyT]

Yes, you are right, Driver-Man realizes the truth. Very good, magic and all, I appreciate that. It's actually inverse situation and instead of ghosting it's blocking. So, when player 2 holds Button A, it will not register when player 1 hits that same Button A. -- Thank you again, and can we settle now that for only one joystick we do not need diodes?

No, it's ghosting, otherwise known as "phantom" switch closures.  "Blocking" is actually deliberately coded into firmware (or software in this case) as a preventative measure to ghosting, and since you were unaware of it's existence, you couldn't have coded for it.  Nor would you need to, if the diodes are left in place, as the circuit was originally designed.

And yes, one joystick (all controls on a single "switched ground") probably does not need diodes, but that's a far cry from how you started this conversation.

[Driver-Man]

No, it's ghosting, otherwise known as "phantom" switch closures.  "Blocking" is actually deliberately coded into firmware (or software in this case) as a preventative measure to ghosting,

Ok, if that's what you call it.

and since you were unaware of it's existence, you couldn't have coded for it.  Nor would you need to, if the diodes are left in place, as the circuit was originally designed.

And yes, one joystick (all controls on a single "switched ground") probably does not need diodes, but that's a far cry from how you started this conversation.

I did not write TGXLPT driver, that was written like 8 years ago, or more, as I said. If you look at MAME source code you should be able to find that same piece of code somewhere, in DOS MAME it was provided via Allegro library. Similarly, I only implemented (copy/paste) that same piece of code in my DOS TSR program which takes TXGLPT1 input and outputs key codes, at arbitrary frequency.



MonMotha,

We are not talking about the same thing. I am not talking about latency nor bandwidth, in fact I'm not talking about USB at all. Keyboard controller/buffer is the "host". Look, you are talking about the "middle", and I'm talking about the two ends:

- Micro controller, located on the device
- Keyboard controller (buffer), located on the computer
============================================


a.) Micro controller, located on the device

There must be some upper limit at what rate Micro controllers can *generate* bits/bytes per second. That is not USB specification, but Micro controller specification and no one came out with any sort of number for that.



b.) Keyboard controller (buffer), located on the computer

* Keyboard controller
http://en.wikipedia.org/wiki/Keyboard_controller_(computing)
- "In computing, a keyboard controller is a device which interfaces a keyboard to a computer. Its main function is to inform the computer when a key is pressed or released. When data from the keyboard arrive, the controller raises an interrupt (a keyboard interrupt) to allow the CPU to handle the input."


* Keyboard buffer
http://en.wikipedia.org/wiki/Keyboard_buffer
- "As the main computer receives each keystroke, it ordinarily appends the character which it represents to the end of the keyboard buffer."


This is not USB disk drive, here the CPU (OS) actually needs to take time off and make sure to put each code in the buffer, and then signal back to the device to send the next one... one by one? This is again not USB specification, this is dictated by mainly by the keyboard controller, and somewhat by the keyboard buffering functionality which is OS specific, or so it would seem.

[SavannahLion]

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.

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.

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.

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.

Then on page two you wrote:

Do you realize MonMotha above confirmed most of what I was saying all along? Except diodes, you got that, you win, but that was beside the main point, my joystick really works, I did not lie to you, I just never got to wire both of them and realize the issue.

Holy crap... you just nominated yourself for the Ass of the Year Award.

---fudgesicle--- this silliness. I'm going to finish up my OSD.

[JustMichael]

For those that have have suffered through this thread this far please queue

Do you realize MonMotha above confirmed most of what I was saying all along? Except diodes, you got that, you win, but that was beside the main point, my joystick really works, I did not lie to you, I just never got to wire both of them and realize the issue.

It isn't about "winning" or "losing", it is about trying to get accurate information out to the people and learning what we don't know.

As long as you have just 1 ground (and no "highs"), then your joystick will work without diodes.  The diodes I added in my picture were to protect the LPT port from being shorted out.

a.) Micro controller, located on the device

There must be some upper limit at what rate Micro controllers can *generate* bits/bytes per second. That is not USB specification, but Micro controller specification and no one came out with any sort of number for that.

If you mean how fast the microcontroller transmits its information to the pc, that would be whatever USB specification it is built to follow.  A Full speed USB device transmits its data to the pc at 12mhz (12 million bits per second).

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

[MonMotha]

MonMotha,

We are not talking about the same thing. I am not talking about latency nor bandwidth, in fact I'm not talking about USB at all. Keyboard controller/buffer is the "host". Look, you are talking about the "middle", and I'm talking about the two ends:

- Micro controller, located on the device
- Keyboard controller (buffer), located on the computer
============================================


a.) Micro controller, located on the device

There must be some upper limit at what rate Micro controllers can *generate* bits/bytes per second. That is not USB specification, but Micro controller specification and no one came out with any sort of number for that.



b.) Keyboard controller (buffer), located on the computer

* Keyboard controller
http://en.wikipedia.org/wiki/Keyboard_controller_(computing)
- "In computing, a keyboard controller is a device which interfaces a keyboard to a computer. Its main function is to inform the computer when a key is pressed or released. When data from the keyboard arrive, the controller raises an interrupt (a keyboard interrupt) to allow the CPU to handle the input."


* Keyboard buffer
http://en.wikipedia.org/wiki/Keyboard_buffer
- "As the main computer receives each keystroke, it ordinarily appends the character which it represents to the end of the keyboard buffer."


This is not USB disk drive, here the CPU (OS) actually needs to take time off and make sure to put each code in the buffer, and then signal back to the device to send the next one... one by one? This is again not USB specification, this is dictated by mainly by the keyboard controller, and somewhat by the keyboard buffering functionality which is OS specific, or so it would seem.

You need to read up on DMA.  I'll reiterate: this isn't a PC-XT.  Lots of stuff happens behind the scenes these days that didn't happen on PCs 20 years ago.  Lots of stuff happens differently than it did on PCs 20 years ago.

In general, USB bypasses "legacy" PC interfaces entirely, though they are sometimes emulated by software for compatibility.  Hence, there is no "keyboard controller" involved in this process.  USB bypasses that old monster.  As an IN transfer occurs from a USB device, the USB host controller chucks the received data into memory and then signals the OS USB driver via a PCI/PCIe interrupt that data is available.  The OS then magically finds that some data happens to exist in memory, either directly addressable (DMA happened) or a ported FIFO somewhere.  The host controller doesn't care if it's a USB keyboard or a USB rocket launcher; it's up to software to make that determination and interpret the data meaningfully.

This data is the received USB frame which happens to include the HID report (in the case of a HID device, such as a keyboard).  The OS then parses that data to map it into OS system keyboard (or mouse, or rocket launcher, or whatever) events and does whatever it feels like to pass that keyboard data on to an application.  It generally merges it with other potential sources of "keyboard" data (PS/2 ports, other USB HID devices, simulated keyboards, etc.) then passes it to any process that has requested to be notified of keyboard events.  The semantics of this process are again OS dependent and in fact even depend on which API you use to ask for keyboard data, but at this point ANY keyboard input mechanism handled by the OS is the same.  It doesn't matter where the data actually came from: this is the "system keyboard input".  Why do you think you can have multiple keyboards connected and still have it all work?

Note that other USB devices will work similarly.  A USB serial port doesn't look like a 16550 UART hanging off the ISA bus.  You can't just bang on a few registers directly to talk to it.  The OS's USB stack talks to it in a completely different manner but exposes the same APIs to user applications.  Since the hardware port at the other end is still an RS-232 level UART, and user software still gets its familiar interface (which never involved banging on registers directly, anyway - user apps talk to the OS driver for serial ports), nobody cares that they actually work completely differently.  The end-to-end user experience is generally the same.

As to what data rate the micro on the "keyboard" can generate, it depends on the micro.  Keeping up with 12Mbps isn't that hard, though.  Even a 16MHz, 8-bit micro can usually pull it off: I've come fairly close on an AT90USB1287 with very non-ideal firmware, and I was only running it at 8MHz.  The bigger 32-bit micros with lots of DMA facilities can often saturate a high speed (480Mbps) USB link.  Given that the actual data rate needed to fully update a 64 input device at 120Hz is only about 8kbps, I'd say that's not an issue.  Reading pin status on a microcontroller at 120Hz is also generally a non-issue.  Pin-change interrupts can be used in many cases to alleviate the CPU load, or it would only take ~30 CPU cycles on a single cycle architecture like modern 8051s and AVR to read a few 8-bit IO ports and just stuff the data directly into the HID report whenever the host polls the endpoint (an 8MHz MCU has about 65000 CPU cycles available for every single endpoint poll if the endpoints are polled at 120Hz).

I have no idea where you're getting your information about how all this stuff works, but you're very misinformed about USB.  You seem to want to apply the exact nature of how PCs worked 20+ years ago to it, when it's quite different.  If you want to have a technical discussion, I'm happy to oblige, but you need to read up on the basics, first.  The USB standard actually does define many of the requirements of the host.  Further information on how the host works is available in the documentation for the particular HCIs (host controller interfaces, of which there are 2 common low-full speed ones: OHCI and UHCI and one high-speed one: EHCI).  There are lots more implementations of the device side (ranging from fixed hardware on keyboard/mouse ASICs to software bit-banged implementations for 8-bit microcontrollers).

[Driver-Man]

It isn't about "winning" or "losing", it is about trying to get accurate information out to the people and learning what we don't know.

I agree.

I'll reiterate: this isn't a PC-XT.

Juts like 386 is not 286, yet they're both x86?

Backwards compatibility, friend or foe?

Code: [Select]

kbRead:
WaitLoop:    in     al, 64h     ; Read Status byte
             and    al, 10b     ; Test IBF flag (Status<1>)
             jz     WaitLoop    ; Wait for IBF = 1
             in     al, 60h     ; Read input buffer

Do you think there is any chance the above piece of code will not work on some PC?


USB Legacy Support, is the title of this argument. Even if your computer came with no other but USB ports you will still have keyboard controller on your motherboard, mouse and keyboard data WILL BE provided via port 60h/64h-IRQ1/IRQ12 interface, even after BIOS POST.


What we really want to know here is how MAME gets the input. If it samples scan codes from port 0x60, then your computer might just as well be PC-XT. -- Do you think MAME has separate routine for PS/2 and USB keyboard, maybe it uses windows system drivers, or something else?

In general, USB bypasses "legacy" PC interfaces entirely, though they are sometimes emulated by software for compatibility.

It is ALWAYS emulated, or at least that's the Windows default settings. Would you like me to compile that program which reads port 0x60 so you can see it will work with your USB keyboard just the same, in either Windows or Linux?

Hence, there is no "keyboard controller" involved in this process.  USB bypasses that old monster.

Can you back that up? I agree some custom USB device can do whatever it wants, use DMA and all, but not the keyboard obviously. -- Could you point me to the piece of low-level code that reads USB keyboard as opposed to PS/2 keyboard, I never seen or heard those two are handled differently.

I have no idea where you're getting your information about how all this stuff works, but you're very misinformed about USB.

It's Driver-Man's instinct, senses tingling and such. I also get information from the fact that the software I write works regardless of the port the keyboard is plugged into. Where do you get your information from? That PDF does not really address any of this, does it? And, did you not just few post earlier express uncertainty about it all:

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


USB is just a "pipe". This is a matter of software implementation (drivers), not USB specification, which only defines the protocol as to how data is parsed and transmitted, which is completely unrelated to how that data is used/stored once retrieved. The only thing that is certain at the end, is actually this compatibility with PC-XT.

[EvilNuff]

...It's Driver-Man's instinct, senses tingling and such....

You're a troll. 

That's my instinct and using your own logic you cannot argue with the accuracy of my statement.

[Osirus23]

You're a troll. 

Yes. Now will everyone please stop. Just STOP.

[Marsupial]

I personally find MonMotha's posts very interesting.

[MonMotha]

It is ALWAYS emulated, or at least that's the Windows default settings. Would you like me to compile that program which reads port 0x60 so you can see it will work with your USB keyboard just the same, in either Windows or Linux?

You're welcome to try.  It will crash on NT (incl. 2k/XP and Vista/7).  NT does not allow userspace processes to perform in/out instructions.  Linux doesn't either unless you call iopl or similar.

Incidentally, accessing the parallel port in this manner will, too.

Such a program would run on Win9x, but I don't think you'll get USB HID keyboard data except on Win95 RTM (which didn't include USB support).  I'm not 100% sure of that, but I think even Win9x disables legacy emulation since it wants direct access to the USB HCI to enable non-HID boot protocol devices to function.  You may also run into all sorts of issues with both Windows and your application simultaneously trying to do I/O to the same locations, and you definitely won't be able to use interrupts.

If your computer comes with no "legacy" keyboard port, you do NOT have a "keyboard controller" on the motherboard.  The BIOS will emulate accesses to the IO ports used by the keyboard controller unless the OS tells it otherwise.  Even if you DO have a "legacy" keyboard port, the BIOS still intervenes in order to provide merged PS/2 and USB HID data via that interface to anything that still uses it (which is pretty much just DOS and some bootloaders).

MAME does not have separate routines for PS/2 and USB input.  MAME *does* use the APIs provided by Windows (or whatever OS is hosting it) for accessing the keyboard data.  You actually don't have a choice, and it would stupid to do it any other way as it wouldn't take into account things other than PS/2 and USB keyboards if you banged on the registers directly like you seem to want to do.  What if the user has a Bluetooth keyboard?  How about an old Sun keyboard hooked up to the parallel port (Linux supports this!)?  What about on-screen keyboards?

I suspect at this point you're either trolling or someone who hasn't programmed a PC since 1990.  One of the core functions of a"real" OS (i.e. something that doesn't just provide a thin wrapper around a fixed architecture) is that it abstracts away hardware functions like this.

[saint]

You're a troll. 

Yes. Now will everyone please stop. Just STOP.

So, why do I let a thread like this keep going?

Despite the condescending/patronizing attitude, it has generated some pretty interesting technical discussions. Until it gets to a point where the rules are being broken I don't see the need to moderate it. Sort the wheat from the chaff if this kind of thing interests you, or bail on the thread if it doesn't

--- saint

[Driver-Man]

You're welcome to try.  It will crash on NT (incl. 2k/XP and Vista/7).  NT does not allow userspace processes to perform in/out instructions.  Linux doesn't either unless you call iopl or similar.

Code: [Select]

void main(){
  while(inportb (0x60)!=1)
    printf("\nKey: %i", inportb(0x60));
}
DOWNLOAD: inC-kbd.zip (kbd.c + kbd.exe)
http://www.mediafire.com/?sd73z3qllhw1e10


Tested it now on WinXP, with both PS/2 and USB,
even with Macinotsh (USB) keyboard,
on Desktop, on Laptop,
and also with 2 keyboards in the same time.

It works.

I suspect at this point you're either trolling or someone who hasn't programmed a PC since 1990.

Troll? What are you accusing me of?


Green Goblin: -"Well, to each his own. I chose my path, you chose the way of the hero. And they found you amusing for a while, the people of this city. But the one thing they love more than a hero is to see a hero fail, fall, die trying. In spite of everything you've done for them, eventually they will hate you. Why bother?"

[SavannahLion]

Code: [Select]

void main(){
  while(inportb (0x60)!=1)
    printf("\nKey: %i", inportb(0x60));
}
DOWNLOAD: inC-kbd.zip (kbd.c + kbd.exe)
http://www.mediafire.com/?sd73z3qllhw1e10


Tested it now on WinXP, with both PS/2 and USB,
even with Macinotsh (USB) keyboard,
on Desktop, on Laptop,
and also with 2 keyboards in the same time.

It works.

Virtualization. NTVDM probably. You'll need to be specific about what compiler you're using. inportb is actually a mnemonic in some compilers.

Also, I haven't actually run your little .exe or run a test compile of my own. I'm in the wrong environment for it.

If I can locate my ten year old C compilers, I'll probably get around to it. Sorry. 

[Driver-Man]

Virtualization. NTVDM probably. You'll need to be specific about what compiler you're using. inportb is actually a mnemonic in some compilers.

That was compiled with Borland Turbo C++ 3.0 (1990). Here is assembler version:

Code: [Select]

.MODEL TINY
.386
.code
org 100h
Main:
  in al, 60h
  cmp al, 1
  je Quit

  mov ah, 02
  mov dl, al
  int   21h
  jmp main

Quit:
  mov   ax,4c00h
  int   21h
end Main
DOWNLOAD: inASM-kb.zip (kb.asm + kb.com)
http://www.mediafire.com/?6zoz6ah7iupji5m


"Backwards compatibility" is serious dilemma, on one hand it steps on the foots of progress, and on the other hand we have all this old software that we can not forget about just like that. Let die the woman you love... or suffer the little children?

[Marsupial]

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

[Driver-Man]

That is, when data is received from the PS/2 keyboard or mouse connected to the keyboard controller, the data is set in the I/O port. The keyboard controller generates IRQ1 (IRQ12) to start the keyboard (mouse) control program of the BIOS/OS/application. The keyboard (mouse) control program reads the key data (mouse data) from the I/O port.

On the other hand, when the USB host controller receives packet data from the USB keyboard or mouse, the data emulation means is started. This data emulation means transforms the packet data into data corresponding to the PS/2 keyboard or mouse, and then transfers it to the I/O port of the keyboard controller. Upon reception of the data, the keyboard controller generates IRQ1 (IRQ12) similar to the case wherein it receives data from the PS/2 keyboard or mouse, thereby starting the keyboard (mouse) control program of the BIOS/OS/application.

http://www.patentstorm.us/patents/6067589/description.html

[Derrick Renaud]

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

I'm not getting involved in this argument.  

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

I will add a little (overly simplistic) info on how emulated input is seen by a games driver.

First let me say that if you want the game to have its input behave exactly like the real game, then use a real game PCB.

As far as MAME's input is handled, all input data is gathered for 1 emulated real time frame.  Lets say 60Hz.  The same thing is done for video and sound.  It needs time to be converted from the original hardware to a format that can be output from the computer.

The thing to remember is that emulated time is different then real time.  They only meet at certain intervals such as v-blank. 1 frame of emulated time is handled much faster then 1 frame of real time.  This is why you can unthrottle a game and make it run much faster.  Well except for games that don't run at 100%.  So emulated time is used to keep the conversion of the video and data in sync.  1 frame of emulated time could actually be done in 1/100th of real time.  Hopefully that makes sense.

So if the emulated game asks for input, it would not actually be asking for it at the proper moment in real time.  MAME could actually stop and wait for real time then poll the input, but that would cause a glitch while the emulation had to start again.  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.  If it is a digital input and it changed during the frame, then MAME just says it changed anytime it is asked during that frame.  If it is analog, and MAME is asked half way through an emulated frame, then MAME will dole out 50% of the change. (Which is why low count spinners seem to move smoothly, but to actually get accurate movement, you need a high count spinner to scale down.  But that is another can of worms.)

Now lets mix in the difference of fixed rate polling of PC hardware.  Using USB, as long as the rate is more then 2 times the frame rate, then the data should be there.  USB's 125Hz is more then two times the 60Hz frame rate.  You can get slightly better accuracy by increasing the poll rate to 500Hz or 1000Hz, but that would be more useful to analog devices.

In other-words, at 125Hz poll rate, the worst case delay is 0.008s.  500Hz is 0.002s worst case delay.  etc.   My reflexes are not that fast.

Feel free to argue about this, but the only thing further I would be able to add is to quote RandyT's post of:

further discussion would cause:

 

Oh, I forgot... As for no diodes when multiplexing inputs,  I say  .  I suppose you could use a multiplexing IC or 2, but you need at least diodes to stop ghosting, or don't muliplex.  See the 2 modes of ButtonBox2 for more info.
http://www.leien.info/buttonbox
http://www.leien.info/buttonbox/bbox2/hardware.htm

There is a reason that TVs, Radios, etc all use diodes to multiplex their button input.  If they were not needed the manufacturer would not spend the $0.0001 each.  Of course a lot of newer TVs and such all use analog multiplexing which does not need diodes.  The newest use capacitive input which is way off topic.

[CheffoJeffo]

As much as I hate to admit it ... Hoopz was right ...

[Derrick Renaud]

I guess I could add one last thing.

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

A basic PC keyboard is not designed for multiple button presses as needed by arcade enthusiasts.  Whereas the input boards have been designed with that in mind.

[MonMotha]

So, I built this using Visual Studio 2005 as a Win32 console application.  inportb is no longer defined by Windows (and hasn't been for a while), so I had to define it myself.  Here's the code I used:

Code: [Select]

#include <stdio.h>

char inportb(void *portid)
{
char value;
__asm mov edx, portid
__asm in al, dx
__asm mov value, al
return value;
}

void outportb(void *portid, char value)
{
__asm mov edx, portid
__asm mov al, value
__asm out dx, al
}

int main(int argc, char* argv[])
{
printf("Keyboard Port Read Test\n");
while(inportb (0x60)!=1)
printf("\nKey: %i", inportb(0x60));
}

Lo and behold, when I run it, it...crashes.  Right on that "in" instruction.  For security, system stability, and a whole host of other reasons, Windows NT won't let a userspace application talk directly to the keyboard controller (amongst lots of things).

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.  Quoting the wikipedia article:

(Edit: Given that you used a 20 year old C compiler that predates the existence of NT, I'm sure you built yours as a DOS application)

When a DOS program running inside a VDM needs to access a peripheral, Windows  will either allow this directly (rarely), or will present the DOS program with a Virtual Device Driver which emulates the hardware using operating system functions. A VDM will systematically have emulations for the Intel 8259A interrupt controllers, the 8254 timer chips, the 8237 DMA, etc.

This emulation would also include the keyboard controller.


Let's attempt to confirm these findings:

I also have a truly ancient copy of Masm laying around.  It generates DOS executables (really, the only difference is the linker and some header stuff that tells Windows what environment to run it in).  I built your assembly version using Masm, and it worked.  This is unsurprising.  Since it's a DOS executable, not a native Win32 executable, NT happily runs it inside NTVDM and emulates the keyboard controller for you.  If I had an old DOS C compiler, I could do the same thing with the C version.

Win9x does not have NTVDM.  Since Win9x is really just a fancy shell on top of DOS, it attempts to run DOS applications with very little virtualization, so I'm not really sure what your code would do on Win9x.  However, Win9x has also been end of life for something like 9 years, now, so I'm going to say it's irrelevant.

[Derrick Renaud]

So, I built this using Visual Studio 2005 as a Win32 console application.  inportb is no longer defined by Windows (and hasn't been for a while), so I had to define it myself.

I use:
http://www.geekhideout.com/iodll.shtml

That is how I read in the random noise pattern for the SN76477 IC. I clocked and read it through the parallel port.

[MonMotha]

So, I built this using Visual Studio 2005 as a Win32 console application.  inportb is no longer defined by Windows (and hasn't been for a while), so I had to define it myself.

I use:
http://www.geekhideout.com/iodll.shtml

That is how I read in the random noise pattern for the SN76477 IC. I clocked and read it through the parallel port.

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.

[Derrick Renaud]

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.

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

[Hoopz]

As much as I hate to admit it ... Hoopz was right ...

QFT

 

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

[Driver-Man]

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.

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?

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

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.

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

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.

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

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

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.

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.

This emulation would also include the keyboard controller.

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.

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

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:

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.

And farther down in the post:

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.

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:

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

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:

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

[DJ_Izumi]

So inconclusion, if you are willing to invest far more effort into trying to get your controls to work, you could save up to 10ms in response time in your emulated games.  Finally your MAME machine will be competative at Donkey Kong... Except that Twin Galaxies won't care about any scores not done on the original hardware.

[DillonFoulds]

I dunno, personally I notice lag when it comes to controls, and I've never noticed lag on my mame cab. Maybe it's just because I've become accustomed to MAME, but then again I haven't noticed lag on N64, and like I said, we can get pretty competitive with Smash Bros. 

In the end, let's see some price points that this will cost!

[DJ_Izumi]

In the end, let's see some price points that this will cost!

Don't forget necessary time to invest and what'd probably be a lot of trouble shooting.

[Driver-Man]

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

1.) Find relevant hardware specification and default software settings

2.) Conclude whether those numbers are "good enough" and see if there is anything that can be improved


Currently we are side-tracked in argument whether USB keyboard data is ALWAYS interfaced via PS/2 emulation and so through the port 0x60 of the keyboard controller, or not. Also, it is not quite clear whether I am really a Driver-Man, or perhaps the Green Goblin (Troll). There is drama, there is dilemma, it's your new summer blockbuster, get your pop-corn and jump in, it's interactive!

I have no idea where you get all your misconceptions but you definitely have a ton of them.... Today, USB doesn't go to port 0x60 in windows nor does it get "converted" to ps/2 protocol.  

a.) My "old" program works on your "modern" computer, yes?

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


Are you saying there is any chance "inportb(0x60)" might not work on some PC?

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.

What the...? Read what exactly? Stop talking about me, just show us the part of "the specification" you are referring to, copy/paste - can you do that?  


OpenHCI - Open Host Controller Interface Specification for USB
(Compaq, Microsoft, National Semiconductor @ 09/14/99 2:33 PM)

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

- "To minimize hardware impact, the Host Controller accesses a USB keyboard and/or mouse using the standard OpenHCI descriptor-based accesses. The emulation code sets up the appropriate Endpoint Descriptors and Transfer Descriptors that cause data to be sent to or received from a USB keyboard/mouse using the normal USB protocols. When data is received from the keyboard/mouse, the emulation code is notified and becomes responsible for translating the USB keyboard/mouse data into a data sequence that is equivalent to what would be produced by a PS/2-compatible keyboard/mouse interface. The translated data is made available to the system through the legacy keyboard interface I/O addresses at 60h and 64h."


What now?

The USB specification already determines the maximum rate that a USB keyboard controller can supply scan codes.

Nonsense. By the way, you are contradicting MonMotha, he said USB does not use keyboard controller at all.

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.

We are not talking about keyboard encoder anymore. We are now talking only about the "keyboard controller", which is located on computer motherboard. Anyway, shell we trust this document then, or not:

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

Keyboard/Mouse Input

The Interrupt Transfer Descriptor for the USB keyboard and/or mouse is processed at the rate established by the Endpoint Descriptor’s location(s) in the interrupt list (a 1-ms rate is the recommended rate for emulation). The Transfer Descriptors are processed as normal by the Host Controller. When a successful transfer of data has occurred from the keyboard, the Transfer Descriptor is moved to the Done Queue by the Host Controller. At the beginning of the next frame when the interrupt associated with the transfer completion is to be signaled, an interrupt is generated. System software should ensure that the Interrupt Routing bit in HcControl is set to 1 so that these interrupts will result in an SMI. Upon receipt of the SMI, the emulation software removes the Transfer Descriptor from the Done Queue, clears the HC IRQ, and translates the keyboard/mouse data into a equivalent PS/2-compatible sequence for presentation to the application software.

For each byte of PS/2-compatible data that is to be presented to the applications software, the emulation code writes to the HceOutput register. The emulation code then sets the appropriate bits in the HceStatus register. If keyboard/mouse interrupts are enabled, setting the HceStatus register bits cause the generation of an IRQ1 for keyboard data and IRQ12 for mouse data. The emulation code then exits and waits for the next emulation interrupt. When the host CPU exits from SMM, it can service the pending IRQ1/IRQ12. This normally results in a read from I/O port 60h. When I/O port 60h is read, the Host Controller intercepts the access and returns the current contents of HceOutput. The Host Controller then also clears the OutputFull bit in HceStatus and de-asserts IRQ1/IRQ12. If the emulation software has multiple characters to send to the application software, it sets the CharacterPending bit in the HceControl register. This causes the Host Controller to generate an emulation interrupt on the next frame boundary after the application has read from port 60h.
--- END QUOTE

[SavannahLion]

That last post of yours is filled contradictory comments. While MonMotha, JustMichael, Randy and Andy's posts are concise and easy to read, your posts are devolving into a gibberish mess.

How can you ask anyone to modify their computer with your BIOS hack, run some software you wrote, or build some circuit hack when all you do is run around telling everyone they're wrong and you're right? Or insisting they show "proof" of their statements when the answers are right there in the documentation? A source that, I believe, was already referenced. You expect us to spoonfeed you this information in a condensed soup complete with recipe and calorie count.

I'm sorry dude, your credence has collapsed. Please, do us all a favor and go read How to Ask Questions the Smart Way by Eric Steven Raymond. Read it thoroughly. Read from beginning to end. Then bookmark and set a CRON/Task Scheduler once a year to remind you to re-read it.

Please.

[MonMotha]

I'm really running out of patience for your blathering.  You clearly have no idea what you're talking about, so please just can it.  I can only hope that this will be my last post to correct your obvious misconceptions.

(FYI,  I have discovered the hard way that you can't let that asm sourced program you posted run very long - it's a very tight loop that produces output far faster than Windows can display it; I had to hard power my system to kill it.  This is arguably a Windows bug, but I figured I'd let people know if they want to try this stuff for themselves)

I have no idea where you get all your misconceptions but you definitely have a ton of them.... Today, USB doesn't go to port 0x60 in windows nor does it get "converted" to ps/2 protocol.  

a.) My "old" program works on your "modern" computer, yes?

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

a) Only when built as a DOS application and running inside NTVDM.  

Note that NTVDM does not exist on 64-bit versions of Windows.  You'll get a "does not support this computer" error when trying to run it (yes, I tried it on 64-bit Windows 7 - screencap of the dialog attached since you won't believe anybody).

b) The keyboard controller is now part of what is commonly referred to as the "SuperIO" chip, usually living on the LPC bus (used to be the ISA bus, but those are gone, now) but sometimes integrated into the "southbridge".

USB legacy support is a BIOS function.  Basically, when a "real" OS that talks directly to the USB HCI doesn't exist, the BIOS will emulate port 0x6n accesses and stuff USB HID keyboard data into it merged with PS/2 port keyboard data.  Once a "real" OS (like Windows or Linux, but NOT DOS) loads, it takes over control of the USB HCI and handles input merging on its own since the OS will have its own APIs to grant userspace processes access to keyboard data.  For applications running in NTVDM (DOS applications), this just happens to be the port 0x6n interface the BIOS originally provided (this is for compatibility).  For native Windows applications, the interface is different.

Are you saying there is any chance "inportb(0x60)" might not work on some PC?

It doesn't work at all how you'd intend on my 64-bit Windows 7 system.  The DOS version of the program can't be run at all due to the lack of NTVDM (and really, does an OS really need to support 20 year old DOS applications?), and the Win32 version crashes due to the attempt to use a privileged instruction (and bypassing this restriction doesn't do what you want, either: see below).  Given that Windows 7 is current, and 64-bit is becoming popular (with good reason), I'd say yeah, there's a good chance "inportb(0x60)" won't work on some PCs.

Note that the Windows API doesn't include "inportb" and hasn't for years.  I had to define it to use it.  If your intent is to say that "inportb" will or won't compile, it won't on anything remotely modern.

Either way ("does it compile?" or "does it work?"), you're sunk.  It doesn't work, at least not how you seem to be wanting it to.

The USB specification already determines the maximum rate that a USB keyboard controller can supply scan codes.

Nonsense. By the way, you are contradicting MonMotha, he said USB does not use keyboard controller at all.

No, he's not.  He's referring to something else.  He's referring to the controller chip on the USB keyboard (the source of the data, rather that the sink).  At least, that's how I read it, and it makes sense in that context.

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.

We are not talking about keyboard encoder anymore. We are now talking only about the "keyboard controller", which is located on computer motherboard. Anyway, shell we trust this document then, or not:

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

Keyboard/Mouse Input

The Interrupt Transfer Descriptor for the USB keyboard and/or mouse is processed at the rate established by the Endpoint Descriptor’s location(s) in the interrupt list (a 1-ms rate is the recommended rate for emulation). The Transfer Descriptors are processed as normal by the Host Controller. When a successful transfer of data has occurred from the keyboard, the Transfer Descriptor is moved to the Done Queue by the Host Controller. At the beginning of the next frame when the interrupt associated with the transfer completion is to be signaled, an interrupt is generated. System software should ensure that the Interrupt Routing bit in HcControl is set to 1 so that these interrupts will result in an SMI. Upon receipt of the SMI, the emulation software removes the Transfer Descriptor from the Done Queue, clears the HC IRQ, and translates the keyboard/mouse data into a equivalent PS/2-compatible sequence for presentation to the application software.

For each byte of PS/2-compatible data that is to be presented to the applications software, the emulation code writes to the HceOutput register. The emulation code then sets the appropriate bits in the HceStatus register. If keyboard/mouse interrupts are enabled, setting the HceStatus register bits cause the generation of an IRQ1 for keyboard data and IRQ12 for mouse data. The emulation code then exits and waits for the next emulation interrupt. When the host CPU exits from SMM, it can service the pending IRQ1/IRQ12. This normally results in a read from I/O port 60h. When I/O port 60h is read, the Host Controller intercepts the access and returns the current contents of HceOutput. The Host Controller then also clears the OutputFull bit in HceStatus and de-asserts IRQ1/IRQ12. If the emulation software has multiple characters to send to the application software, it sets the CharacterPending bit in the HceControl register. This causes the Host Controller to generate an emulation interrupt on the next frame boundary after the application has read from port 60h.
--- END QUOTE

The section you're quoting simply describes how emulation software in the BIOS should operate.  Most BIOSes do provide this emulation so that DOS can be used.  Bootloaders (e.g. LILO, GRUB, the Windows boot menu, etc.) that need a user interface also commonly use the BIOS on PCs to do that I/O since it's one of the few standard methods available without needing lots of driver code.  The BIOS needs this code to support USB keyboards in its configuration menus, anyway, so it's not a big deal to pass this support on.

Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off).  They provide their own input APIs that don't involve applications directly accessing IO port 0x60, so this emulation is not needed and would conflict with direct access to the USB HCI (necessary for non-boot HID devices).  They are aware of the multiple sources of keyboard data on modern PCs and don't need the data merged into the ancient interface DOS expects.  These OSes *do* still talk to port 60, but only to retrieve actual PS/2 keyboard data.  They *also* talk to the USB HCI directly to receive HID data (and other USB data).  This HID data is then merged with data from other sources (PS/2 port, Bluetooth HID, onscreen keyboard, etc.) and presented to userspace applications in whatever manner the OS uses.  Typically, this is a kernel syscall or a file stream (standard input).


So, to settle this (or at least attempt to, since I'm sure you won't believe me, anyway), I did some further testing:

For grins, I unblocked access to port 0x60 on my 32-bit Windows XP SP3 machine using the "userport" program I mentioned in a previous post to Derrick Renaud.  All this program (which includes a kernel-mode driver) does is enable userspace processes to access the IO ports you specify.  The system a laptop, and Linux says that the onboard keyboard is on the PS/2 port (this is typical).  I ran the Win32 native application that bangs directly on port 0x60.  It got data from the onboard PS/2 keyboard but neither of the USB keyboards I had attached.  This is consistent with what I just said: Windows reads port 0x60 for PS/2 keyboard data but gets USB data from elsewhere (directly from the HCI) and merges it together itself for presentation to userspace applications via the Win32 API.  Since reading port 0x60 bypasses the Win32 API, it will only get data actually present on port 0x60 which is PS/2 data.

The DOS version *DOES* get data from all sources because it's running inside NTVDM.  NTVDM uses the conventional Windows APIs to get keyboard data before stuffing it into an emulated port 0x60 interface.  Hence, any keyboard Windows knows about will be passed to a DOS application inside NTVDM via port 0x60.  This ONLY happens because that DOS application is running inside an EMULATION LAYER to emulate DOS.  That emulation layer is NOT present for native Win32 applications, and it's not necessary because native Win32 applications don't bang directly on the hardware.

[JustMichael]

Currently we are side-tracked in argument whether USB keyboard data is ALWAYS interfaced via PS/2 emulation and so through the port 0x60 of the keyboard controller, or not. Also, it is not quite clear whether I am really a Driver-Man, or perhaps the Green Goblin (Troll). There is drama, there is dilemma, it's your new summer blockbuster, get your pop-corn and jump in, it's interactive!

From that statement we can surmise troll... definitely troll.

I have no idea where you get all your misconceptions but you definitely have a ton of them.... Today, USB doesn't go to port 0x60 in windows nor does it get "converted" to ps/2 protocol.  

a.) My "old" program works on your "modern" computer, yes?

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

a) Can your old program work on a modern computer?  In a dos box, yes it can through EMULATION.  In case you haven't noticed the E in MAME stands for EMULATION.

b) The USB Legacy Support allows a modern computer to have its bios emulate USB keyboards and mice as PS/2 devices for non-USB aware environments like DOS.

Are you saying there is any chance "inportb(0x60)" might not work on some PC?

Running in a current windows environment (not an emulated dos box), the program will error out.  Which error displayed would depend upon which windows environment you are running.

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.

What the...? Read what exactly? Stop talking about me, just show us the part of "the specification" you are referring to, copy/paste - can you do that?  

You can read the HID 1.11 specification here: http://www.usb.org/developers/devclass_docs/HID1_11.pdf

OpenHCI - Open Host Controller Interface Specification for USB
(Compaq, Microsoft, National Semiconductor @ 09/14/99 2:33 PM)

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

- "To minimize hardware impact, the Host Controller accesses a USB keyboard and/or mouse using the standard OpenHCI descriptor-based accesses. The emulation code sets up the appropriate Endpoint Descriptors and Transfer Descriptors that cause data to be sent to or received from a USB keyboard/mouse using the normal USB protocols. When data is received from the keyboard/mouse, the emulation code is notified and becomes responsible for translating the USB keyboard/mouse data into a data sequence that is equivalent to what would be produced by a PS/2-compatible keyboard/mouse interface. The translated data is made available to the system through the legacy keyboard interface I/O addresses at 60h and 64h."


What now?

Did you even read the document you are quoting?  I am betting that you did not.  Here is the second sentence:

The purpose of OpenHCI is to accelerate the acceptance of USB in the marketplace by promoting the use of a common industry software/hardware interface.

When USB keyboards and mice were starting out they WERE often emulated as ps/2 devices for compatibility.  If they weren't, you couldn't have used them with DOS programs.  Here is the paragraph previous to the one you quoted:

OVERVIEW
To support applications and drivers in non-USB-aware environments (e.g., DOS), the Host Controller needs to provide some amount of hardware support for the emulation of a PS/2 keyboard and/or mouse by their USB equivalents. For Open HCI, this emulation support is provided by a set of registers that are controlled by code running in SMM. Working in conjunction, this hardware and software produces approximately the same behavior-to-application code as would be produced by a PS/2-compatible keyboard and/or mouse interface.

From what I have seen, windows seems to be a pretty USB-aware environment.  Is there some reason you brought a document that talks about DOS when we are talking about USB HID devices in windows?

The USB specification already determines the maximum rate that a USB keyboard controller can supply scan codes.

Nonsense.

Nonsense?  You can't transmit data faster than the specification allows.  I bet you ignored the sentences that followed the one you quoted:

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.

By the way, you are contradicting MonMotha, he said USB does not use keyboard controller at all.

By keyboard controller I was meaning the chip in the keyboard or the USB HID device.  The next quote from you shows that you understood what I meant.  Yes, I should have used the word "encoder" to be proper.  Monmotha means that the keyboard controller inside the pc is NOT used for USB. 

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.

We are not talking about keyboard encoder anymore. We are now talking only about the "keyboard controller", which is located on computer motherboard. Anyway, shell we trust this document then, or not:

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

Keyboard/Mouse Input

The Interrupt Transfer Descriptor for the USB keyboard and/or mouse is processed at the rate established by the Endpoint Descriptor’s location(s) in the interrupt list (a 1-ms rate is the recommended rate for emulation). The Transfer Descriptors are processed as normal by the Host Controller. When a successful transfer of data has occurred from the keyboard, the Transfer Descriptor is moved to the Done Queue by the Host Controller. At the beginning of the next frame when the interrupt associated with the transfer completion is to be signaled, an interrupt is generated. System software should ensure that the Interrupt Routing bit in HcControl is set to 1 so that these interrupts will result in an SMI. Upon receipt of the SMI, the emulation software removes the Transfer Descriptor from the Done Queue, clears the HC IRQ, and translates the keyboard/mouse data into a equivalent PS/2-compatible sequence for presentation to the application software.

For each byte of PS/2-compatible data that is to be presented to the applications software, the emulation code writes to the HceOutput register. The emulation code then sets the appropriate bits in the HceStatus register. If keyboard/mouse interrupts are enabled, setting the HceStatus register bits cause the generation of an IRQ1 for keyboard data and IRQ12 for mouse data. The emulation code then exits and waits for the next emulation interrupt. When the host CPU exits from SMM, it can service the pending IRQ1/IRQ12. This normally results in a read from I/O port 60h. When I/O port 60h is read, the Host Controller intercepts the access and returns the current contents of HceOutput. The Host Controller then also clears the OutputFull bit in HceStatus and de-asserts IRQ1/IRQ12. If the emulation software has multiple characters to send to the application software, it sets the CharacterPending bit in the HceControl register. This causes the Host Controller to generate an emulation interrupt on the next frame boundary after the application has read from port 60h.
--- END QUOTE

More of this DOS document??  As far as I know we are supposed to be talking about a windows environment or did that change too when you said we aren't talking about encoders anymore?

Oh ya almost forgot, there is a pretty picture for you on page 10 of that 1.11 spec.  It is in section 4.4 and shows how a USB HID device communicates with the pc (or in this case the HID driver).  For some reason I just can't seem to find any PS/2 stuff in this specification.  Could that be because it isn't used in USB?   

[Driver-Man]

Or insisting they show "proof" of their statements when the answers are right there in the documentation?

Yes, all I told you can also be found @ www.usb.org  -- Don't you find it ridiculous you can not find a piece of text to quote and confirm your claims?

Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off).

According to what? Show me.


OpenHCI - Open Host Controller Interface Specification for USB
(Compaq, Microsoft, National Semiconductor @ 09/14/99 2:33 PM)

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

That specification above, there is nothing to support your claims, you think they forgot to mention it there? Your PDF, why there is nothing there? The Internet, the whole world wide web contains no piece of text to support your claims?

I ran the Win32 native application that bangs directly on port 0x60.  It got data from the onboard PS/2 keyboard but neither of the USB keyboards I had attached.  This is consistent with what I just said: Windows reads port 0x60 for PS/2 keyboard data but gets USB data from elsewhere (directly from the HCI) and merges it together itself for presentation to userspace applications via the Win32 API.  Since reading port 0x60 bypasses the Win32 API, it will only get data actually present on port 0x60 which is PS/2 data.

No source code, no binary downloads, can we not try it out?

The DOS version *DOES* get data from all sources because it's running inside NTVDM.  NTVDM uses the conventional Windows APIs to get keyboard data before stuffing it into an emulated port 0x60 interface.  Hence, any keyboard Windows knows about will be passed to a DOS application inside NTVDM via port 0x60.  This ONLY happens because that DOS application is running inside an EMULATION LAYER to emulate DOS.

According to what? Why is it OpenHCI USB specification only confirms what I said? Why can you not quote any source to confirm your claims? Show me.

In a dos box, yes it can through EMULATION.

Emulation of KEYBOARD CONTROLLER and translation to PS/2 is in HARDWARE, not DOS BOX. See the specification and links above.

What the...? Read what exactly? Stop talking about me, just show us the part of "the specification" you are referring to, copy/paste - can you do that?

You can read the HID 1.11 specification here: http://www.usb.org/developers/devclass_docs/HID1_11.pdf

Can you actually *say* (copy/paste) it?

What part are you talking about exactly?

More of this DOS document??  As far as I know we are supposed to be talking about a windows environment or did that change too when you said we aren't talking about encoders anymore?

DOS document?!?

Open Host Controller Interface Specification for USB

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf


Uh. Windows? Ok, show me anything, anything at all where it even suggest your claims are correct. Why is it you can not point any specific part in any of these documents? Show me.

For some reason I just can't seem to find any PS/2 stuff in this specification.  Could that be because it isn't used in USB?

You are looking at the wrong document, you can not find anything there to support your point either, though you can find some hints to confirm mine, of course.


This is THE specification:

Open Host Controller Interface Specification for USB

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

[newmanfamilyvlogs]

from the PDF you linked:

To minimize hardware impact, the Host Controller accesses a USB keyboard and/or mouse using
the standard OpenHCI descriptor-based accesses. The emulation code sets up the appropriate
Endpoint Descriptors and Transfer Descriptors that cause data to be sent to or received from a
USB keyboard/mouse using the normal USB protocols. When data is received from the
keyboard/mouse, the emulation code is notified and becomes responsible for translating the USB
keyboard/mouse data into a data sequence that is equivalent to what would be produced by a
PS/2-compatible keyboard/mouse interface. The translated data is made available to the system
through the legacy keyboard interface I/O addresses at 60h and 64h. Likewise, when data/control
is to be sent to the keyboard (as indicated by the system writing to the legacy keyboard interface),
the emulation code is notified and becomes responsible for translating the information into
appropriate data to be sent to the USB keyboard/mouse through the transfer descriptor
mechanism.

If that's legacy, then what superseded it?

[CheffoJeffo]

It's like deja vu all over again!



 

[Driver-Man]

If that's legacy, then what superseded it?

Yes, that's interesting question. I'd say, when they decided to make UNIVERSAL interface, at that point all other SPECIFIC interfaces that USB can mimic today became "legacy". Does that make sense?

[newmanfamilyvlogs]

it wont make sense until you give me solid official documentation, and not opinions.

[Driver-Man]

An OHCI for USB standard document from Compaq, Microsoft and National Semiconductor

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

http://en.wikipedia.org/wiki/Ohci


That IS the official documentation. What now?

Am I wrong? Do you have a statement to make?

[JustMichael]

More of this DOS document??  As far as I know we are supposed to be talking about a windows environment or did that change too when you said we aren't talking about encoders anymore?

DOS document?!?

Open Host Controller Interface Specification for USB

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf


Uh. Windows? Ok, show me anything, anything at all where it even suggest your claims are correct. Why is it you can not point any specific part in any of these documents? Show me.

When you quote from Appendix B of that document then of course I am going to refer to it as a DOS document because that is what that section is about.  Try reading the overview of the section.  It tells what the section is about.  As far as showing you, I already did.  In fact last reply I quoted the document (page 136, Appendix B) that you linked to.  This time I increased the font size and colored a word red so you don't miss it a second time.

OVERVIEW
To support applications and drivers in non-USB-aware environments (e.g., DOS), the Host Controller needs to provide some amount of hardware support for the emulation of a PS/2 keyboard and/or mouse by their USB equivalents. For Open HCI, this emulation support is provided by a set of registers that are controlled by code running in SMM. Working in conjunction, this hardware and software produces approximately the same behavior-to-application code as would be produced by a PS/2-compatible keyboard and/or mouse interface.

For some reason I just can't seem to find any PS/2 stuff in this specification.  Could that be because it isn't used in USB?

You are looking at the wrong document, you can not find anything there to support your point either, though you can find some hints to confirm mine, of course.


This is THE specification:

Open Host Controller Interface Specification for USB

ftp://ftp.compaq.com/pub/supportinformation/papers/hcir1_0a.pdf

Even looking in the document that you quote, I can only find references to PS/2 in Appendix B which is the DOS section of the document.  I still can't find references to PS/2 elsewhere in the spec.

Driver-Man,
don't expect any more replies from me.  I am done with this thread.  You have shown that you only read parts of documents and seem to ignore the important parts of what you do read.  You seem to think that if a specification applies to a tiny area (like DOS) then it applies to everything in sight.  You quote stuff and bill it as one thing but in reality (our reality, not yours) the quote is of something else entirely.  All too often you seem to have this mentality that says "I don't care! I am right and the world is wrong!"  Sounds like you still have a lot of growing up to do and good luck in that.  Oh one last thing, just in case you were unaware DOS and Windows are two different operating systems.

[Bender]

Awww come on guys the is the funniest thing I've seen in a while

[Derrick Renaud]

Food for thought....

Turn off USB legacy support in your BIOS.  How odd that windows still can use the keyboard.

cough... Raw Input ... cough... supports multiple keyboards ... cough... which is obviously fed through the old DOS BIOS... cough...    Welcome to 2001 and WinXP.

 

Driver-Man, you really should read the informative posts on this thread as a whole, instead of just picking out words from them to support your view.  People are/were trying to be helpful to you.  You totally missed the point of how MAME, due to the whole concept of a computer emulating real hardware, can not (well it can, but shouldn't) stop and wait for real time when code on the emulated CPU asks to read the hardware input device.  So implementing an actual instant read port would serve no purpose, and using the parallel port to do so would be far from instant.

[Driver-Man]

Derrick,

You would like me to believe how "Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off).", right?

Ok.

Is it too much then if I ask you to show me a piece of text, anywhere on the whole world wide web, that says something among those lines? If there is no such explicit statement in the whole world, then what makes you believe it is true? How did you learn about it?

Turn off USB legacy support in your BIOS...

Yes, I tried that and I can still read port 0x60 with my program just the same, no change. Everyone will again say it's DOS Box (NTVDM), but it is clear from all the links and documents that emulation is embedded in hardware/firmware. -- C'mon, if indeed Windows handles USB keyboard without keyboard controller and port 0x60, then someone must have said that somewhere before.

[Derrick Renaud]

You would like me to believe how "Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off).", right?

Driver-Man,
tell me, how does the old, antique, BIOS support multiple keyboards?  MAME can map 2 separate keyboards individually to 2 separate control inputs as needed by mahjong games.

Please read up on Raw Input.
http://msdn.microsoft.com/en-us/library/ms645536(VS.85).aspx

It provides direct access to each keyboard, which are also combined into a single keyboard for old time use.

Edit: the BIOS is not turned off.  It is just provided virtually if needed, as others have already stated.  Well, unless you are using DOS and not an OS from the last 10 years.

[Derrick Renaud]

Another thing to think about is key debounce.  This takes time, more time then any USB lag.  Especially if you set the USB rate to 500Hz.

[Driver-Man]

Driver-Man,
tell me, how does the old, antique, BIOS support multiple keyboards?  MAME can map 2 separate keyboard individually to 2 seperate games inputs as needed by mahjong games.

I will answer your questions if you answer mine

You would like me to believe how Windows turns off PS/2 emulation of USB keyboard. Is it too much then if I ask you to show me a piece of text, anywhere on the whole world wide web, that says something among those lines? If there is no such explicit statement in the whole world, then what makes you believe it is true? How did you learn about it then?

Please read up on Raw Input.
http://msdn.microsoft.com/en-us/library/ms645536(VS.85).aspx

What about it? Please make a statement, I have no idea what are you trying to say.

[SavannahLion]

Awww come on guys the is the funniest thing I've seen in a while

Oh what the hell. Driver is a moron anyways.

 

[Driver-Man]

Actually I found something there...
http://msdn.microsoft.com/en-us/library/ms645546(v=VS.85).aspx

Quote:
- "In this sample, an application wants raw input from the keyboard and mouse but wants to ignore legacy window messages (which would come from the same keyboard and mouse). "

Code: [Select]

RAWINPUTDEVICE Rid[2];
       
Rid[0].usUsagePage = 0x01;
Rid[0].usUsage = 0x02;
Rid[0].dwFlags = RIDEV_NOLEGACY;   // adds HID mouse and also ignores legacy mouse messages
Rid[0].hwndTarget = 0;

Rid[1].usUsagePage = 0x01;
Rid[1].usUsage = 0x06;
Rid[1].dwFlags = RIDEV_NOLEGACY;   // adds HID keyboard and also ignores legacy keyboard messages
Rid[1].hwndTarget = 0;

if (RegisterRawInputDevices(Rid, 2, sizeof(Rid[0])) == FALSE) {
    //registration failed. Call GetLastError for the cause of the error
---end quote


Do you notice the word "IGNORE", and the sentence "which would come from the same keyboard and mouse".

Obviously legacy input is still there, sure you can "ignore" it too, as you will, but that will not make it go away.

[newmanfamilyvlogs]

http://www.microsoft.com/whdc/archive/usbhost.mspx?pf=true#usbh1

The time line in Figure 1 starts with a power-up (cold boot) event on the PC.
•   
Immediately after power-up and for some period of time, the BIOS controls the PC and the host controller. During this time interval, a user should be able to use a USB keyboard to enter BIOS Setup and then use all keys on the USB keyboard that are valid during BIOS Setup.
•   
If the user does not choose to enter BIOS Setup, at some point the BIOS starts the operating system and the operating system takes control of the PC and the host controller. As shown in Figure 1, code in a routine in the operating system host controller driver performs the necessary steps to hand off control of the legacy keyboard support function from the BIOS to the operating system host controller driver (in this article, that routine is called StopBIOS).
•   
The next event shown in Figure 1 occurs when the user employs the Shutdown menu to shutdown to MS-DOS. This causes the host controller driver to be unloaded; before unloading it executes a routine that performs the necessary steps to hand off control of the legacy keyboard support function to the BIOS (in this article, that host controller driver routine is called StartBIOS).

This kinda looks like it.

[Derrick Renaud]

 

I give up.  You are right.  BIOS has supported multiple keyboards since day 1. Everything goes through the BIOS, even though Windows shuns programs using it.  It has nothing to do with old APIs being provided from new APIs.  I imagine when they make new APIs it is for the sole purpose of wrapping the old APIs in a new layer of confusion that provides no benifit.

Thanks for making me see the light.  I will now move on to more important things.
D.

 

[Derrick Renaud]

Do you notice the word "IGNORE", and the sentence "which would come from the same keyboard and mouse".

Obviously legacy input is still there, sure you can "ignore" it too, as you will, but that will not make it go away.

I should not respond to this, but your logic is amusingly baffling.  

It does not make it go away, but it does not mean it is being used.  The program (MAME) can and does have direct access to the input device (keyboard, mouse, etc.)  which I have stated, gets combined into the legacy device.  Which eventually gets sent to the virtual BIOS for those old programs that need it.

Heck even the remote desktop mouse and keyboard get combined into the legacy devices.  MAME could be coded to use those as seperate input too.  It would serve no purpose, which is why they are ignored to stop MAME users from complaining about it, but I digress.

The simple logic of the fact that MAME can access individual keyboards which you can not do with the BIOS, means something else must be going on.

Anyways, good luck and keep tring to connect the dots.

[Driver-Man]

cotmm68030,

That's probably the best link so far.

http://www.microsoft.com/whdc/archive/usbhost.mspx?pf=true#usbh1


Operating System Takes Control of the UHCI Host Controller

- Configure the host controller.
- Enable a USB keyboard and mouse.
- Set up the host controller scheduler.

* Route USB keyboard and mouse input to the 8042 Keyboard Controller (KBC).

============

BIOS legacy support means emulation is provided in hardware/firmware. No BIOS legacy support means there will need to be a driver loaded somewhere in main CPU memory, which is provide by Windows but not DOS. In either way that emulation runs pretty much the same code which communicates with keyboard controller and port 0x60.

[Driver-Man]

It does not make it go away, but it does not mean it is being used.  

Heck even the remote desktop mouse and keyboard get combined into the legacy devices.

Ok, I'll believe that. Thank you.

[Malenko]

but how do you know the JAMMA PCB is legal?


seriously, you are the worst kind of idiot. You quote docs out of context and when you are rebutted by like 50 different people all saying the same thing, you still assume you are the only correct one. I don't know a metric ton of APIs or port specifications, but when something new comes out, its still supports the old stuff during the change over. I skimmed over some of the docs you and others have posted, and I get it better then you do.

[Jack Burton]

In the Street Fighter community there has always been the suspicion that USB connections add lag in some way that isn't present in the older types of connections that you found in consoles like the NES, SNES, PSX, and PS2.  And of course on an original PCB.   So this conversation is very interesting to me and that community.  

It is the current belief over on the shoryuken.com forums  that the Playstation Network and Xbox Live versions of Super Street Fighter II HD Remix suffer from small amount of input delay compared to the Dreamcast and arcade versions.  

In my opinion, having played the DC and arcade versions since they each respectively came out I can definitely tell the HD versions on the new consoles do not feel as quick and solid.  However I recognize that there are probably many other factors coming into play that could cause this.  The process of porting a game from CPSII to DC to cross platform Xbox/Ps3 could introduce all kinds of strange things.  

I've read this whole thread.  At first I was hoping that by using the parallel port I could restore that quick, precise NES-like control that I enjoy that I have never found replicated on a PC.  

Currently the closest I've been able to come to that is by using a Microsoft Sidewinder connected to a gameport and the emulator Nestopia.  It just feels better than using a PS3 Six-axis or Xbox 360 pad.  

Is there really any lower input delay over the gameport or is it all just in my head?  
I'm serious, I really don't know.  It could be that the stiffer buttons on the sidewinder just give the illusion of quicker, more responsive control.  

I do not like this Driver-man.

I respect the opinions of most of the posters in this thread other than him a great deal. Collectively they have been my greatest teachers on all things emulation.  
Thanks to you all.  

So my question to RandyT, Mon Mothma, Andy, etc.  Is there any real added benefit to using Ps/2, Serial, or parallel port connections?  

From a stand point of the standards themselves, and not whatever factors are involved in the PC they are connected to.  In an ideal environment are there any differences in performance between USB, PS/2, Serial, NES, gameport, and parallel port connections?

If it is even a small advantage I'm completely willing to go the extra length for it. Convenience is not important to me.  My main emulation machine has an LPT port on it and I'm willing to build a custom controller for it (diodes, resistors and all)  if it will get me just a little advantage.  

[AndyWarne]

Food for thought....

Turn off USB legacy support in your BIOS.  How odd that windows still can use the keyboard.

Absolutely. Thats the easiest way to prove that keyboard input (post Windows 98) does not go via the motherboard keyboard controller, as turning this off disables this path.
Prior to XP, Windows could read the keyboard either via the USB controller or via the legacy route. If there was a problem with the USB controller (eg no drivers installed) the USB keyboard would still work, but it was slow, because it was routing through the legacy support. In fact it was noticeably slow in gaming. The original troubleshooting page for the I-PAC had a check for Windows 98 to ensure the USB controller was working and just to be sure, disable legacy USB Support in case the I-PAC ended up going through legacy.
In XP if the USB controller is not working, the USB keyboard will not work as there is no legacy path.

The correct situation is Windows 98 could use the Port 60 route but did not unless it had to. XP does NOT use the port 60 route. Anything on the web which states otherwise is either outdated or simply wrong.

[DJ_Izumi]

It is the current belief over on the shoryuken.com forums  that the Playstation Network and Xbox Live versions of Super Street Fighter II HD Remix suffer from small amount of input delay compared to the Dreamcast and arcade versions.  

In my opinion, having played the DC and arcade versions since they each respectively came out I can definitely tell the HD versions on the new consoles do not feel as quick and solid.

...Do you mean Marvel Vs. Capcom 2?  Cause I'm pretty certian that SSFIIHDR was never on DC or Arcades.

That said, didn't the Dreamcast and NAOMI use the very USB like 'Maple Bus'?  The maple bus as I understand is a serial bus with a lot in common with USB.

[Jack Burton]

It is the current belief over on the shoryuken.com forums  that the Playstation Network and Xbox Live versions of Super Street Fighter II HD Remix suffer from small amount of input delay compared to the Dreamcast and arcade versions.  

In my opinion, having played the DC and arcade versions since they each respectively came out I can definitely tell the HD versions on the new consoles do not feel as quick and solid.

...Do you mean Marvel Vs. Capcom 2?  Cause I'm pretty certian that SSFIIHDR was never on DC or Arcades.

That said, didn't the Dreamcast and NAOMI use the very USB like 'Maple Bus'?  The maple bus as I understand is a serial bus with a lot in common with USB.

HD Remix is merely a tweaking of some of the gameplay features of the game.   It is 99% identical to Super Turbo.  The responsiveness of the controls should be identical under ideal circumstances.  And of course there is HD Super Turbo mode as well.  

One of my friends was looking at the NAOMI specs a while back as part of an emulation project and relayed to me that it was indeed some manner of serial input over a usb cable.  

[AndyWarne]

So my question to RandyT, Mon Mothma, Andy, etc.  Is there any real added benefit to using Ps/2, Serial, or parallel port connections?  

It would be nice to be able to prove by testing rather than theorising, but this is not easy to do in terms of overall response. What is easy to test though is lag between simultaneously-pressed keys.
The Passmark keyboard test (www.passmark.com) displays this figure. On an I-PAC connected via PS/2 it is a consistent 1ms. When connected via USB it is a consistent zero.

[DJ_Izumi]

HD Remix is merely a tweaking of some of the gameplay features of the game.   It is 99% identical to Super Turbo.  The responsiveness of the controls should be identical under ideal circumstances.  And of course there is HD Super Turbo mode as well.

I have great difficulty believing this.  Other sources put SSF2HDR as being 'heavily modified' and this makes sense.  Going from CPS-2 and Dreamcast (Which probably just emulated the CPS-2 hardware rather than being a port) to PS3 and 360, adding 720p visuals, adding full music as opposed to something sythnsized in the chip, and then getting all of that running as a NATIVE piece of software on multicore hardware.  I just think it's highly unlikely to say it's 99% the same in terms of the 'guts' of the problem and how it works.  It would be more reasonable to assume the built an original game while copying the rule set from the old game.  It's certianly not a 'port' by any reasonable use of the word so comparing them is like apples and orange.

Something like MvC2 which is PORTED from the NAOMI code to it's other platforms, including PS3 and 360 is a much more reasonable comparison.  But then look at the PS2 and Xbox1 ports of MvC2 which were largely considdered to be plagued with minor issues or 'broken' as the fighting game fanatics call it.

[Driver-Man]

You quote docs out of context and when you are rebutted by like 50 different people all saying the same thing, you still assume you are the only correct one. I don't know a metric ton of APIs or port specifications, but when something new comes out, its still supports the old stuff during the change over. I skimmed over some of the docs you and others have posted, and I get it better then you do.

Little human, do you even know why do you hate me? Never mind, I forgive you, but there is no need to be emotionally unstable over technical discussion and blame me for your inability to understand, relax. You have some opinion, that's great, all you have to do now is find some source and quote it here to back it up.

Turn off USB legacy support in your BIOS.  How odd that windows still can use the keyboard.

Thats the easiest way to prove that keyboard input (post Windows 98) does not go via the motherboard keyboard controller, as turning this off disables this path.

False. Turning BIOS legacy support off will only disable hardware level PS/2 emulation, and so Windows will use its own emulation driver, that will be doing the SAME THING - interfacing with keyboard controller and port 0x60.


Is this Microsoft page outdated and simply wrong:
http://www.microsoft.com/whdc/archive/usbhost.mspx

XP does NOT use the port 60 route. Anything on the web which states otherwise is either outdated or simply wrong.

XP does NOT use the port 60 route. Can you show us anything on the web that says so? Or perhaps that's some mysterious unspoken truth everyone is supposed to believe without questioning?

[saint]

You quote docs out of context and when you are rebutted by like 50 different people all saying the same thing, you still assume you are the only correct one. I don't know a metric ton of APIs or port specifications, but when something new comes out, its still supports the old stuff during the change over. I skimmed over some of the docs you and others have posted, and I get it better then you do.

Little human, do you even know why do you hate me? Never mind, I forgive you, but there is no need to be emotionally unstable over technical discussion and blame me for your inability to understand, relax. You have some opinion, that's great, all you have to do now is find some source and quote it here to back it up.

This attitude has to stop now or you have to find another forum.

--- saint

[Driver-Man]

"seriously, you are the worst kind of idiot."


...and you are willing to tolerate that kind of attitude?

[Jack Burton]

HD Remix is merely a tweaking of some of the gameplay features of the game.   It is 99% identical to Super Turbo.  The responsiveness of the controls should be identical under ideal circumstances.  And of course there is HD Super Turbo mode as well.

I have great difficulty believing this.  Other sources put SSF2HDR as being 'heavily modified' and this makes sense.  Going from CPS-2 and Dreamcast (Which probably just emulated the CPS-2 hardware rather than being a port) to PS3 and 360, adding 720p visuals, adding full music as opposed to something sythnsized in the chip, and then getting all of that running as a NATIVE piece of software on multicore hardware.  I just think it's highly unlikely to say it's 99% the same in terms of the 'guts' of the problem and how it works.  It would be more reasonable to assume the built an original game while copying the rule set from the old game.  It's certianly not a 'port' by any reasonable use of the word so comparing them is like apples and orange.

Something like MvC2 which is PORTED from the NAOMI code to it's other platforms, including PS3 and 360 is a much more reasonable comparison.  But then look at the PS2 and Xbox1 ports of MvC2 which were largely considdered to be plagued with minor issues or 'broken' as the fighting game fanatics call it.

I believe the case with ST is that it was ported from the original source code from the CPS2 to the Dreamcast.  I do not think it is an emulator.  I only have my own recollections of things I've read on SRK over the years to back this up.  I can probably find out if you're curious.  

The C or C++ source for the Dreamcast version is what was used for the PSN and Xbox live versions with probably some heavy modification.  I do know for a fact that they did not build "an original game using the same rules".

However, this is off-topic here so If you want to continue dicussion I can do so via pm's and probably link you to some threads on srk.  

[CheffoJeffo]

Is this Microsoft page outdated and simply wrong:
http://www.microsoft.com/whdc/archive/usbhost.mspx

Support for USB and Legacy Keyboards and Mouse Devices
Updated: December 4, 2001

[Driver-Man]

Ok, CheffoJeffo, can you find better and more up-to-date document? There is no point in saying all these documents are wrong and my quotes out of context, just find any document that says otherwise, anything at all.

[MonMotha]

Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off).

According to what? Show me.

Did you read the rest of the post?  I ran a native Win32 application that read port 0x60.  I got PS/2 data, but not USB data.  If emulation of USB keyboards via port 0x60 were present, I would have gotten USB keyboard data via that interface, as well, but I didn't.

I ran the Win32 native application that bangs directly on port 0x60.  It got data from the onboard PS/2 keyboard but neither of the USB keyboards I had attached.  This is consistent with what I just said: Windows reads port 0x60 for PS/2 keyboard data but gets USB data from elsewhere (directly from the HCI) and merges it together itself for presentation to userspace applications via the Win32 API.  Since reading port 0x60 bypasses the Win32 API, it will only get data actually present on port 0x60 which is PS/2 data.

No source code, no binary downloads, can we not try it out?

Oh wait, you DID read that part!  You just conveniently ignored it above.

As to where the source is, I already posted it previously in this thread.  It's the same code you built for DOS just with inportb and outportb defined since Windows doesn't include them anymore.  It's the same program that crashes unless you take special consideration (e.g. using "userport") to unblock raw IO port access.  Userport also comes with source code, if you really want to read it.

The DOS version *DOES* get data from all sources because it's running inside NTVDM.  NTVDM uses the conventional Windows APIs to get keyboard data before stuffing it into an emulated port 0x60 interface.  Hence, any keyboard Windows knows about will be passed to a DOS application inside NTVDM via port 0x60.  This ONLY happens because that DOS application is running inside an EMULATION LAYER to emulate DOS.

According to what? Why is it OpenHCI USB specification only confirms what I said? Why can you not quote any source to confirm your claims? Show me.

OpenHCI has nothing to do with this.  Heck, if you're on an Intel motherboard, you probably don't even have an OCHI controller.  You probably have a UHCI one.

We know that NT runs DOS applications inside NTVDM.  DOS applications can't run directly on NT, so it has to.
We know that NTVDM emulates legacy BIOS interfaces.

There are lots of articles all over the place that describe this, including Microsoft's website.
Try some of these (3 links).  The last one is especially informative, though it's also the oldest, referring to NT 4.0. 
The other articles confirm that this still applies to Win2k, upon which XP is based.  This KnowledgeBase article shows that it still applies to WinXP, too.

Just search that last page link of the 3 for NTVDM (second hit), and you'll find this little tidbit:

MS-DOS-based applications run on Windows NT 4.0 in a process called an NT Virtual DOS Machine (NTVDM). NTVDM is a 32-bit Windows application that simulates an Intel 486 computer running MS-DOS.

To run MS-DOS-based applications, the NTVDM creates a virtual computer including support for:
•Intel x86 instructions, provided by the Instruction Execution Unit
•Read-only memory basic input and output (ROM BIOS) interrupt services, provided by the MS-DOS emulation module
•MS-DOS Interrupt 21 services, provided by the MS-DOS emulation module
•Virtual hardware for devices, such as the screen and keyboard, provided by Virtual Device Drivers

(Emphasis mine)

In other words:

NTVDM uses the conventional Windows APIs to get keyboard data before stuffing it into an emulated port 0x60 interface.  Hence, any keyboard Windows knows about will be passed to a DOS application inside NTVDM via port 0x60.

(Isn't it handy when you can quote yourself?)

Basically, any DOS application you run on modern (meaning less than 10 years old) Windows is running inside an emulation layer.  This means that attempting to extrapolate basic underlying system behavior from the behavior of a DOS application running on said modern Windows OS will give misleading and even irrelevant results.

Is this Microsoft page outdated and simply wrong:
http://www.microsoft.com/whdc/archive/usbhost.mspx

Did you read that page?  That page basically says that, since the BIOS supports legacy emulation of USB devices upon startup and this would conflict with Windows talking to USB devices directly, Windows has to kick it out of the way so that it can talk to USB devices directly.  Look at Figure 1 and read the section "Operating System Takes Control of the OHCI Host Controller" (there is also one detailed for UHCI controllers).


Yeah, you're trolling.  I'd just ignore you, but I'd be afraid that others on here would believe the crap you're spewing and make poor decisions based on it.

So my question to RandyT, Mon Mothma, Andy, etc.  Is there any real added benefit to using Ps/2, Serial, or parallel port connections? 

From a stand point of the standards themselves, and not whatever factors are involved in the PC they are connected to.  In an ideal environment are there any differences in performance between USB, PS/2, Serial, NES, gameport, and parallel port connections?

If it is even a small advantage I'm completely willing to go the extra length for it. Convenience is not important to me.  My main emulation machine has an LPT port on it and I'm willing to build a custom controller for it (diodes, resistors and all)  if it will get me just a little advantage. 

Not really.

The parallel port is handy if you don't want to buy anything, are willing to do a fair bit of software hackery, and only need up to 13 inputs.  Beyond that the matrixing/multiplexing required makes it inferior to dedicated, multi-input encoders in terms of either complexity or having ghosting issues.  While it's easy to make this a very non-laggy interface, you have to possibly worry about switch bounce and such with directly connected inputs, and a properly designed USB interface has no effective lag by providing data faster than the PC software needs it.

The serial port has no real usage in this application.  It requires software hackery like the parallel port would while being much slower than USB and still requiring a "smart" outboard device to communicate.  It would only really be useful if you had a microcontroller with a UART (common) but not a USB interface (these are less common and more complex) that you were already using and wanted to interface to your PC.

PS/2 ports offer no real advantages over a properly designed USB encoder.  I'd only use it if USB was unavailable or I was building my own quick-and-dirty hardware and didn't want to deal with the hardware/software complexity of USB.

USB is readily available and, when applied properly, has no real downsides to its use with gaming and emulation.  It's one of the more complex solutions to implement for the designer, but it provides plug-and-play ease for the user once the design has been done.

[Jack Burton]

Thank you mon mothma.

Reading this:

http://en.wikipedia.org/wiki/Game_port

I was struck by a few pieces of information.

"Unlike most other joystick connectors (and controllers) during the early days of home computing and game consoles, the game port is actually analog rather than digital, relying on some form of ADC to interpret joystick movements. "

"While other joystick standards (such as Atari or NES joysticks) are very easy and straightforward for programmers to use, the game port requires careful programming and well-timed software interrupt  triggering to read an input. This of course caused performance issues as reading the game port took a notable amount of CPU time, especially compared to systems with a 'normal' digital (TTL) joystick port."

I don't know if this would actually make a practical difference, but it does sound like my faith in the gameport as a low lag connection was misplaced.  Looks like it needs to be read just like USB does.  It is not the same as an NES controller.  Of course in practical use I'm guessing the amount of processing time required is trivial for gameport just like it is for USB.  Right? 

[MonMotha]

Thank you mon mothma.

Reading this:

http://en.wikipedia.org/wiki/Game_port

I was struck by a few pieces of information.

"Unlike most other joystick connectors (and controllers) during the early days of home computing and game consoles, the game port is actually analog rather than digital, relying on some form of ADC to interpret joystick movements. "

"While other joystick standards (such as Atari or NES joysticks) are very easy and straightforward for programmers to use, the game port requires careful programming and well-timed software interrupt  triggering to read an input. This of course caused performance issues as reading the game port took a notable amount of CPU time, especially compared to systems with a 'normal' digital (TTL) joystick port."

I don't know if this would actually make a practical difference, but it does sound like my faith in the gameport as a low lag connection was misplaced.  Looks like it needs to be read just like USB does.  It is not the same as an NES controller.  Of course in practical use I'm guessing the amount of processing time required is trivial for gameport just like it is for USB.  Right? 

The PC game port kinda sucks, yeah.  It consists of a half-assed ADC for the joystick axes and a few digital inputs for buttons.  There's no IRQ available; the CPU has to poll it, and the A/D conversion timing is, historically, at least, largely CPU driven (hence that article complaining about timing issues).  The as for interfacing arcade game controls, there's 4 button inputs available, and they can be talked to in a similar way to the PC parallel port.

The NES controller is basically a bunch of buttons hooked up to a parallel load, serial out shift register (74xx166 style).  The NES would strobe the load/latch input, then shift out all the bits serially.  Effectively, this forms something like a SPI interface (and I've seen the SPI port of a microcontroller used to talk to it).  Since the number of bits is low (8 buttons: 4 for the D-Pad, A, B, Start, Select), even a moderate clock frequency of e.g. 83.33kHz (used by the NES) results in a maximum usable poll rate of 9.26kHz (83.33k/9 - 9 to include an extra bit time to latch the data) if you polled it continuously.  This document describes the protocol in some detail.

This type of serial transfer can also be bit-banged pretty easily on a parallel port, and I know there are lots of examples out there.  The CPU overhead required isn't too outrageous, though it probably requires busy loops (wasted CPU time) since it's not worth yielding CPU time during the period between clock edges on most OSes (even "highly interactive" Linux configurations only preempt 1000 times/sec).


Many other game console controllers work similarly.  The Playstation Dualshock (2), for example, is basically a smarter version of that.  The host can perform serial transfers to manipulate what mode the controller is in or ask for controller state data.  If the host requests controller state data, the controller responds with a bunch of bits that map to the various buttons as well as some wider bit fields that represent the position of the analog sticks.  For the Dualshock 2 with analog buttons, the buttons are more than a single bit; they are instead several bits that represent a number related to how hard the user is pressing the button.

Bit banged parallel port interfaces for dualshocks are also pretty common.  When talking to a dedicated microcontroller or similar, a SPI controller or USART can be used.


The Neo-Geo AES and Atari sticks are some of the few that really are just a bunch of totally unmultiplexed digital inputs on a connector.  Since that was also how the arcade controls worked, and MVS and AES hardware was virtually identical, this makes some sense for the Neo-Geo, and Atari sticks just don't have very many inputs.

[Driver-Man]

That page basically says that, since the BIOS supports legacy emulation of USB devices upon startup and this would conflict with Windows talking to USB devices directly, Windows has to kick it out of the way so that it can talk to USB devices directly.  Look at Figure 1 and read the section "Operating System Takes Control of the OHCI Host Controller" (there is also one detailed for UHCI controllers).

No. That is not really about Windows, but any OS. It says that OS has the choice to use BIOS drivers, if present. It also says PS/2 emulation is within SMM, which is transparent to the operating system and application software, and so this functionality stays as a part of whatever higher-level operation is wrapped around it.

Basically, any DOS application you run on modern (meaning less than 10 years old) Windows is running inside an emulation layer.  This means that attempting to extrapolate basic underlying system behavior from the behavior of a DOS application running on said modern Windows OS will give misleading and even irrelevant results.

How about this "Passmark keyboard test" from www.passmark.com, AndyWarne was talking about?

I get minimum of 7-8 ms lag between each scan code sent with USB keyboard. With PS/2 keyboard this lag is 4-5 ms. That comes down to about two keys per frame @ 60FPS. And so, I was right after all, at least as far as my own computer goes. -- I also tried several "USB sniffer" programs, and according to this little investigation I see key codes are always transmitted one by one, and there are all sorts of lags and two-way communication going on in between each packet.

Anyway, do you accept 'Passmark keyboard test' as "benchmark" program to settle this argument?

The parallel port is handy if you don't want to buy anything, are willing to do a fair bit of software hackery, and only need up to 13 inputs.  Beyond that the matrixing/multiplexing required makes it inferior to dedicated, multi-input encoders in terms of either complexity or having ghosting issues.

- "are willing to do a fair bit of software hackery,"

Not true, many emulators have this driver built in, plus there are "joystick" OS specific drivers for Windows, Linux and DOS. This is mature and very well tested interface enjoyed by many people who know about it, for the last 8 years or more.


- "and only need up to 13 inputs."

TGXLPT sets the maximum number of inputs, 9x7 = 63.


- "Beyond that the matrixing/multiplexing required makes..."

8 bits at the time, gathering 24 inputs in just three instructions...
Did you not say that is exactly how arcade games originally did it?

[AndyWarne]

False. Turning BIOS legacy support off will only disable hardware level PS/2 emulation, and so Windows will use its own emulation driver, that will be doing the SAME THING - interfacing with keyboard controller and port 0x60.


Is this Microsoft page outdated and simply wrong:
http://www.microsoft.com/whdc/archive/usbhost.mspx

Its outdated.

XP does NOT use the port 60 route. Anything on the web which states otherwise is either outdated or simply wrong.


XP does NOT use the port 60 route. Can you show us anything on the web that says so? Or perhaps that's some mysterious unspoken truth everyone is supposed to believe without questioning?

OK here you go: http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true#E2C

Also go into Device Manager and look at a HID keyboard, and Driver Details. There you will find i8042prt.sys (the emulation driver) is not there.

[Driver-Man]

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.

I did not respond to this earlier because I did not see any time intervals in that screen shot there (1st page). -- It never occurred to me before we can sort all this out without any arguments actually. AndyWarne was right to come along with such testing tools, I wish I paid more attention to that before, as that's the easiest and most reliable source of information, especially since no one believes the word I say, for some reason, and what's even better such software will tell every one about their specific situation with their own particular computer.

Anyhow, if we forget about everything else, 2ms intervals between each scan code would give you about 8 keys per frame max @ 60FPS, if you are not using arrow keys that is. However, releasing or *TAPPING* buttons, just as using arrow keys, will emit double scan codes, which can leave you with less than 8 keys per frame. -- Perhaps that's "good enough", but if it is 2 keys per frame like on my computer, well that's not "good enough", not for me anyway.

[MonMotha]

That page basically says that, since the BIOS supports legacy emulation of USB devices upon startup and this would conflict with Windows talking to USB devices directly, Windows has to kick it out of the way so that it can talk to USB devices directly.  Look at Figure 1 and read the section "Operating System Takes Control of the OHCI Host Controller" (there is also one detailed for UHCI controllers).

No. That is not really about Windows, but any OS. It says that OS has the choice to use BIOS drivers, if present. It also says PS/2 emulation is within SMM, which is transparent to the operating system and application software, and so this functionality stays as a part of whatever higher-level operation is wrapped around it.

Yes, PS/2 emulation happens within SMM.  The SMM takes data from the USB HCI and dumps it into the emulated port 0x60 interface.  However, that document also details how Windows disables this emulation so that it can take control of the USB HCI directly.  A different procedure is used for OHCI and UHCI, but both processes result in the same thing: SMM emulation is disabled (by causing the USB HCI to never generate any SMI signals to activate it) and the OS (whatever it is, in this case Windows) can talk to the HCI directly.

If you think that document says that emulation is left on while Windows is running, you're not reading it right.

I'm guessing the process differs some now that EHCI (and whatever USB 3.0 uses) is around, but it's still the same concept: the "real" OS disables SMM emulation of legacy keyboard/mouse for USB keyboard/mouse so that it can take direct control over the USB HCI.  The OS is then responsible for handling all USB devices, including HID boot protocol keyboards and mice, on its own.  The OS will still ask port 0x60 for actual PS/2 keyboard data.

Basically, any DOS application you run on modern (meaning less than 10 years old) Windows is running inside an emulation layer.  This means that attempting to extrapolate basic underlying system behavior from the behavior of a DOS application running on said modern Windows OS will give misleading and even irrelevant results.

How about this "Passmark keyboard test" from www.passmark.com, AndyWarne was talking about?

I get minimum of 7-8 ms lag between each scan code sent with USB keyboard. With PS/2 keyboard this lag is 4-5 ms. That comes down to about two keys per frame @ 60FPS. And so, I was right after all, at least as far as my own computer goes. -- I also tried several "USB sniffer" programs, and according to this little investigation I see key codes are always transmitted one by one, and there are all sorts of lags and two-way communication going on in between each packet.

Anyway, do you accept 'Passmark keyboard test' as "benchmark" program to settle this argument?

Looks like it's probably a native Win32 application, so NTVDM is not in play.

You'll note that 1/125th of a second is 7.87ms.  7-8ms of lag is consistent with a 125Hz polling rate.  This is the forced polling rate for low-speed USB HID devices in Windows.  Most keyboards are low-speed, so Windows will poll them at 125Hz regardless of what they otherwise may ask for.

I'm not surprised that PS/2 keyboards are slightly less laggy than a 125Hz polled USB keyboard.  While the PS/2 keyboard clock is usually only ~100kHz (less than 1/10th the bit clock of even low speed USB), the keyboard controller has a real interrupt to signal the CPU with, so it can potentially get data there very quickly once it is received.

Note that Andy says his IPAC keyboard encoder has a polling rate of 500Hz.  Since the IPAC is a full speed device, Windows will use the polling rate specified in its descriptor.  A 500Hz polling rate would mean one poll every 2ms or about 4 times faster than a normal keyboard.  I'd be interested to see the passmark lag results for an IPAC or other HID device with a faster than typical polling rate.

Note also that games (especially arcade games being emulated in MAME) only check the inputs at a certain rate, regardless of how often new input data may be available.  For arcade games, this is typically once per frame.  Since the framerate is usually ~60Hz, as long as new data is available at least that often (and 120Hz+ would guarantee it), there's little to be gained from higher polling rates or lower input lag.

The parallel port is handy if you don't want to buy anything, are willing to do a fair bit of software hackery, and only need up to 13 inputs.  Beyond that the matrixing/multiplexing required makes it inferior to dedicated, multi-input encoders in terms of either complexity or having ghosting issues.

- "are willing to do a fair bit of software hackery,"

Not true, many emulators have this driver built in, plus there are "joystick" OS specific drivers for Windows, Linux and DOS. This is mature and very well tested interface enjoyed by many people who know about it, for the last 8 years or more.


- "and only need up to 13 inputs."

TGXLPT sets the maximum number of inputs, 9x7 = 63.


- "Beyond that the matrixing/multiplexing required makes..."

8 bits at the time, gathering 24 inputs in just three instructions...
Did you not say that is exactly how arcade games originally did it?

I didn't say that it was slow or had high overhead (in fact, I specifically mentioned that it can be a very low latency interface and at least hinted that application can be electrically simple, but of course you neglected to quote any of that).  I said that it is more complex than many users will want to deal with.  You say that TGXLPT is built into many emulators, and while that may be true, you have to go to some trouble to make raw parallel port access work on WinNT (to include XP).  This is more trouble than some users may want to deal with.  In fact, I can only find references to using MAME with that TGXLPT interface when running MAME on DOS, but it may support it on Windows provided the user goes to the trouble of enabling raw port access or installing a 3rd party driver.  USB (and PS/2, for that matter) keyboard encoders are literally plug-and-play.

What I meant by matrixing or multiplexing is that either external multiplexors (ICs) are required or a matrix has to be built to handle more than 13 inputs.  The tgxlpt interface you linked to is a matrix.  If you don't use a butt-ton of diodes, a matrix will quickly have problems with ghosting (potentially any time more than 2 inputs are triggered).  Many users don't want to wire up a ton of diodes, and I don't blame them.  Matrixes are fine when ghosting is not an issue, e.g. on a TV remote control, but we generally don't use them on arcade controls for this reason.

Either a digitally multiplexed or a matrixed solution will require more IO instructions to read the whole thing.  For your tgxlpt interface you seem to adore, you read 5 inputs at a time (on the status port) then 4 inputs (on the control port) and have to manipulate the data port to scan the matrix.  Each group of 5 inputs requires 3 IO instructions plus potentially a brief spinloop delay (wasting CPU time) to let the matrix settle (this may or may not be required depending on stray capacitance and how fast IO instructions actually run on your CPU).  So, to read all 63 inputs (the 7 groups of 9) requires at least 7*3=21 instructions plus instructions required to correct polarities and re-pack the data into 8-bit variables if desired.  Not that any of this really matters given how fast CPUs are, these days.  The issue with multiplexing and matrixing is really more of a physical implementation hassle.

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.

I did not respond to this earlier because I did not see any time intervals in that screen shot there (1st page). -- It never occurred to me before we can sort all this out without any arguments actually. AndyWarne was right to come along with such testing tools, I wish I paid more attention to that before, as that's the easiest and most reliable source of information, especially since no one believes the word I say, for some reason, and what's even better such software will tell every one about their specific situation with their own particular computer.

Anyhow, if we forget about everything else, 2ms intervals between each scan code would give you about 8 keys per frame max @ 60FPS, if you are not using arrow keys that is. However, releasing or *TAPPING* buttons, just as using arrow keys, will emit double scan codes, which can leave you with less than 8 keys per frame. -- Perhaps that's "good enough", but if it is 2 keys per frame like on my computer, well that's not "good enough", not for me anyway.

You're reading it wrong.  Every 2ms, a HID report frame is transferred to the host.  This report frame contains a large number of scancodes.  In the trace Andy posted, 5 scancodes were sent every 2ms, and there's plenty of unused positions (having NULL 0x00 data) in the report (it's cut off on the display, even), suggesting that the device could send quite a few more.  USB HID devices do not send key up/key down events for each key like a PS/2 device does; they instead send a "report" every time they are polled that lists the entirety of the keys pressed (up to a maximum limit).  The IPAC sends this report every 2ms (or rather tells the host to request the report every 2ms, which it does).  They can do this because USB is pretty fast (1.5Mbps or 12Mbps) compared to the PS/2 AT keyboard interface (~10-20kbps).

Thus, there is NO limit on the number of keys pressed per frame other than the number of keys the device can handle being held down at once.  While this number is typically 6 for conventional keyboards as that's what is used in boot protocol mode, it's possible to make a device where this limit is "the number of keys physically present", and I believe Andy has said that this is how the IPAC is set up.  Thus, the IPAC could handle you simultaneously pressing every input on the encoder in one 2ms interval (good luck!) then releasing them all simultaneously just 2ms later (again, good luck!).  How HID reporting works is all detailed in the USB HID specification we've all been asking you to read.  Clearly, you haven't done so.

[Driver-Man]

OK here you go: http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true#E2C

Touché!

Figure 1. Architecture for Legacy Support for USB and PS/2


Figure 2. Architecture after the operating system takes control



CONGRATULATIONS!!! The winner is you!

And, bonus points for diagrams. Thank you.

[Driver-Man]

If you think that document says that emulation is left on while Windows is running, you're not reading it right.

You were telling the truth after all, but points go to AndyWarne. You are informative indeed, but at the end Andy won with single elegant hit, right between Driver-Man's eyes, oouch! In any case, I thank you too. -- Perhaps it was unreasonable for me to ask for such evidence, but at least we established one more point, slightly less relevant now when we can obtain actual real-world measurements with the software tools such as 'keyboard testers" and "USB sniffers". Your persistence was not in vain, but the battle goes on.... with great power comes great responsibility!

Anyway, do you accept 'Passmark keyboard test' as "benchmark" program to settle this argument?

Looks like it's probably a native Win32 application, so NTVDM is not in play.

I'll take that as a "yes".

You'll note that 1/125th of a second is 7.87ms.  7-8ms of lag is consistent with a 125Hz polling rate.

Let's also make a note that is what it is, and that's ONE KEY per 8ms. -- Your "pipe" can be big and wide, but if there is only a tiny hole at the end where "water" can come out (heh), then that little hole is what will define the maximum "flow rate", hence the name "bottleneck".

We are looking for the bottleneck and USB protocol is not it, move on. My USB sniffer says USB keyboard does indeed transfer 8 bytes long packages, so that can probably do 6 keys at once, and 2 bytes for modifiers, I guess.


HOWEVER, that 8 byte "USB buffer" does not get copied as bunch to some "usb keyboard buffer", but each byte goes to port 0x81, which is pretty much USB equivalent of PS/2 port 0x60. The point is, "entrance" to keyboard buffer is one byte wide again, and that is the "bottleneck".

Every 2ms, a HID report frame is transferred to the host.  This report frame contains a large number of scancodes.  In the trace Andy posted, 5 scancodes were sent every 2ms, and there's plenty of unused positions (having NULL 0x00 data) in the report (it's cut off on the display, even), suggesting that the device could send quite a few more.

Ok, you can send as many as you like as often as you like. But, of what use is that if you need to plug each byte separately, one by one, to port 0x81, and possibly even wait until application (OS) clears the port before able to put another scan code in, just like with PS/2 and port 0x60.

This is why it is important that we establish benchmark software for READING the input. According to "Passmark keyboard test", regardless of 8 bytes per 8ms, it still can still read only ONE KEY in that time-window, or so it says.


=====
And, for the love of drugs, why has no one taken my "dramatic persona" as a joke? What in the world is so offensive about me fooling around with "Spider-Man" spoof? It's allegory, it's a joke, it's to make it more interesting for me, to add some drama and provoke response, to see if anyone will come up with some interesting come-backs.... But that was only 2%, and Saint saw that. He was smart enough to see through my "theatricality", and wise enough to allow it continue for the sake of information. I admire that. Thank you Saint.

[Marsupial]

OK here you go: http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true#E2C

Touché!

Figure 1. Architecture for Legacy Support for USB and PS/2


Figure 2. Architecture after the operating system takes control



CONGRATULATIONS!!! The winner is you!

And, bonus points for diagrams. Thank you.

What, you needed drawing to understand/believe what's been said and referrenced all along???

[Marsupial]

=====
And, for the love of drugs, why has no one taken my "dramatic persona" as a joke? What in the world is so offensive about me fooling around with "Spider-Man" spoof? It's allegory, it's a joke, it's to make it more interesting for me, to add some drama and provoke response, to see if anyone will come up with some interesting come-backs.... But that was only 2%, and Saint saw that. He was smart enough to see through my "theatricality", and wise enough to allow it continue for the sake of information. I admire that. Thank you Saint.

So you were a troll indeed.

thanks for the proof.

[RandyT]

Note also that games (especially arcade games being emulated in MAME) only check the inputs at a certain rate, regardless of how often new input data may be available.  For arcade games, this is typically once per frame.  Since the framerate is usually ~60Hz, as long as new data is available at least that often (and 120Hz+ would guarantee it), there's little to be gained from higher polling rates or lower input lag.

If anyone is to take anything away from this sillyness, it should be the nugget quoted above.  Anything above what would provide absolute accuracy for the intended application is absolutely of no use.  Period.

RandyT

[AndyWarne]

Ok, you can send as many as you like as often as you like. But, of what use is that if you need to plug each byte separately, one by one, to port 0x81, and possibly even wait until application (OS) clears the port before able to put another scan code in, just like with PS/2 and port 0x60.

This is total gibberish. Anything more at this point is going to simply be troll-food.
End of story.

[SavannahLion]

=====
And, for the love of drugs, why has no one taken my "dramatic persona" as a joke? What in the world is so offensive about me fooling around with "Spider-Man" spoof? It's allegory, it's a joke, it's to make it more interesting for me, to add some drama and provoke response, to see if anyone will come up with some interesting come-backs.... But that was only 2%, and Saint saw that. He was smart enough to see through my "theatricality", and wise enough to allow it continue for the sake of information. I admire that. Thank you Saint.

Because it's lame. It's stupid. It's immature. It's disrespectful to Saint and the community as a whole. It's clear that you do not respect those who know a hell of a lot more than you. Worse, you present patently incorrect information as absurdly correct then blame everyone else who is correct as wrong, wrong, wrong. Then you insist on being spoonfed the information condensed, itemized and fully referenced. Then when someone does point you to what you need to read, you just hop around asking, "where? where? where?"

What if the discussion had been about wiring up LED's and you told everyone to wire up Randy's LED lightbar directly to 120v? Or told everyone that they didn't need an isolation transformer?

This was just about application layers. Last time it was copyright. What's the next load of nonsense?

I say enough with the theatrical nonsense. It's not needed or required here.

If you have a question or want to present your work for peer review, then do so without all the "theatrical" ---That which is odiferous and causeth plants to grow---.

[Driver-Man]

So you were a troll indeed.

I can not respond, nor improve, unless I know what are you actually complaining about. What are you accusing me of? What am I doing wrong and how does that hurt you or anyone?

If anyone is to take anything away from this sillyness, it should be the nugget quoted above.  Anything above what would provide absolute accuracy for the intended application is absolutely of no use.  Period.

RandyT

Only Sith deals in absolutes.

Would you mind if we go on and measure it anyway?

Why do you not make USB keyboard encoders, but only PS/2?

This is total gibberish. Anything more at this point is going to simply be troll-food. End of story.

Do you mind if we actually measure it, may I?

TEST: Press Q+W+E+R at the same time, hold for a while, and then release them in the same


* USBTrace 1.3.0
http://www.topshareware.com/USBTrace-transfer-42419.htm






* Passmark keyboard test
http://www.passmark.com/products/keytest.htm




It is clear in from both programs that regardless of USB keyboard packet size, there can only be retrieved a maximum of ONE KEY per 8ms, thus 4 simultaneous key presses, like in my example above, will still need to communicate four packets, with lag between each one that equals to Windows default USB polling rate, on this particular computer of mine. As I was saying all along.



Yes, SavannahLion, I do have a question.

Please let me know the numbers you get with these two programs. Press [Q+W+E+R] at the same time, hold for a while and release them in the same, then simply capture the screenshots and show us how many keys per second is your computer capable of. Can you do that, please?


- "Mutants. Since the discovery of their existence they have been regarded with fear, suspicion, often hatred. Across the planet, debate rages... Either way it is a historical fact: Sharing the world has never been humanity's defining attribute."

[RandyT]

Only Sith deals in absolutes.

Reality = not your bag, eh?

Why do you not make USB keyboard encoders, but only PS/2?

Somewhat spotty compatibility with older OSes when you deviate from the "boot compatible" keyboard device.  I even have a device that should be boot compliant which works fine under 98SE and XP, but performs poorly for gaming under 2K.  Haven't tested it with Win7 yet, but I'll bet it's ok.  If it is, it will probably see the light of day eventually.  PS/2 just works, though, and I've seen a lot of folks here resort to using it when the USB side of things doesn't go their way.  That's why I tend to coax folks into using PS/2 for key input if they have the port available to them, and have never had anyone be disappointed with the performance they experience for doing so.  If nothing else, it does an excellent job for this application, and doesn't use up a USB port that could be used for something else a little less mundane.

RandyT

[JustMichael]

Passmark does NOT calculate the keys per second correctly:

[Malenko]

I wish I knew why we are all so inclined to be your personal google. 2 "big threads" by you, both you dont really read the info provided until someone posts up some pictures for you. Guess I'll start replying with words written in a venn diagram via MSPaint and post in GIF format but I think even that effort would be wasted.

What exactly was the point of this thread again?

[JustMichael]

What exactly was the point of this thread again?

Now that is a very good question! 

[Driver-Man]

What exactly was the point of this thread again?

Everyone can obtain their own numbers now, after that, the point is whatever you choose it to be. You could also ask your friendly neighborhood Driver-Man to make you a better driver for that crappy USB connection of yours.

Now that is a very good question!

Don't you see 7ms lag between each key would mean only about TWO KEYS per frame @60 FPS animation?
If you don't see what kind of impact that can have on game play, then this is perfect forum to ask about it.


===
Yes, that program does not calculate 'key/sec' correctly, possibly it gets confused with buffering, so sometimes keys will keep coming long after you stop pressing any keys, which might very well be the Windows fault, and if MAME uses that same way to read keyboard, than the MAME too would inherit that same buffering bug/behavior. I never noticed anything like it though, but perhaps I did not try hard enough. You? Have you seen any bugs like that in MAME?

What, you needed drawing to understand/believe what's been said and referrenced all along???

I suppose you could say that, yes. Why?



Do you not see the "bottleneck"?

[AndyWarne]

It is clear in from both programs that regardless of USB keyboard packet size, there can only be retrieved a maximum of ONE KEY per 8ms, thus 4 simultaneous key presses, like in my example above, will still need to communicate four packets, with lag between each one that equals to Windows default USB polling rate, on this particular computer of mine. As I was saying all along.

I despair, I really do...

You can see from your USB trace that your keyboard is only sending one key increment on each subsequent packet. So its no surprise that the Passmark test is picking up each key 7ms after the previous one. You have already had the limitations of the keyboard matrix scan system explained to you, and I have also previously posted a USB trace which shows the result of a system which does not use a matrix (I-PAC).
I also stated before that the Passmark lag when using an I-PAC is zero. You dont appear to believe this, so, although I am not sure why, I took a screenshot:

[Driver-Man]

You can see from your USB trace that your keyboard is only sending one key increment on each subsequent packet. So its no surprise that the Passmark test is picking up each key 7ms after the previous one.

Your USB trace shows a packet is sent for each key, just the same as mine.




DIFFERENCE:
- Your USB packets contains all the keys, each 32 bytes long
- My USB packets contain some sequence, each 8 bytes long

- In your case there is 2ms lag in between each packet
- I can make 2ms lag by simply setting polling rate to 500Hz

You are not really achieving anything by sending the full information in the first 32 bytes, since you will still be sending as many of those packets as keys were pressed, just like my USB trace shows too. You are stuffing 5x32 = 160 bytes down the USB pipe just to signal 5 keys are down!?

I also stated before that the Passmark lag when using an I-PAC is zero. You dont appear to believe this, so, although I am not sure why, I took a screenshot:

Your USB trace contradicts that. Operating System is different?  Have you been fiddling with your USB polling rate? -- I think you should try that again with the same operating system where you run that USB trace, they can not both be true, so I think you have some bug, perhaps buffer overflow with all those unnecessary bytes sent there, superfluously.

[Marsupial]

netiquette...

An "Internet troll" or "Forum Troll" or "Message Board Troll" is a person who posts outrageous message to bait people to answer. Forum Troll delights in sowing discord on the forums.  A troll is someone who inspires flaming rhetoric, someone who is purposely provoking and pulling people into flaming discussion.  Flaming discussions usually end with name calling and a flame war.
 
A classic troll is trying to make us believe that he is a genuine skeptic with no hidden agenda.  He is divisive and argumentative with need-to-be-right attitude, "searching for the truth",  flaming discussion, and sometimes insulting people or provoking people to insult him.  Troll is usually an expert in reusing the same words of its opponents and in turning it against them.

They usually have an agenda. Very few trolls come to out of pure skepticism. A Troll is generally a person who is extremely skeptical of the main forum subject.
He is generally interested to make other forum members look stupid. A troll will sometimes use insults to provoke other people to insult him. Then, he will complain to moderators of being insulted and will request that his opponents get banned from further discussion.

He (and in 90% of cases it is he) tries to start arguments and upset people.

Sometimes, Internet troll is trying to spin conflicting information, is questioning in an insincere manner, flaming discussion, insulting people, turning people against each other, harassing forum members,  ignoring warnings from forum moderators.

Trolling is a form of harassment that can take over a discussion. Well meaning defenders can create chaos by responding to trolls. The best response is to ignore it, or to report a message to a forum moderator. Moderators usually delete troll messages or block trolls.  Negative emotions stirred up by trolls leak over into other discussions. Normally affable people can become bitter after reading an angry interchange between a troll and his victims, and this can poison previously friendly interactions between long-time users.

Finally, trolls create a paranoid environment, such that a casual criticism by a new arrival can elicit a ferocious and inappropriate backlash.

When trolls are ignored they step up their attacks, desperately seeking the attention they crave. Their messages become more and more foul, and they post ever more of them.

Alternatively, they may protest that their right to free speech is being curtailed. 

Perhaps the most difficult challenge for a webmaster is deciding whether to take steps against a troll that a few people find entertaining. Some trolls do have a creative spark and have chosen to squander it on being disruptive. There is a certain perverse pleasure in watching some of them. Ultimately, though, the webmaster has to decide if the troll actually cares about putting on a good show for the regular participants, or is simply playing to an audience of one -- himself.

Next time you are on a message board and you see a post by somebody whom you think is a troll, and you feel you must reply, simply write a follow-up message entitled "Troll Alert" and type only this:

The only way to deal with trolls is to limit your reaction and not to respond to trolling messages.  It is well known that most people don't read messages that nobody responds to, while 99% of forum visitors first read the longest and the largest threads with the most answers.
 

FYI: trolling is NOT encouraging the community, in the long run it is irritating to the community members, the moderators, and only helps in encouraging people to not read interesting threads anymore. Nothing good can come out of a troll.

If the moderators don't have a good discussion with the man that talks about himself in the 3rd person, I encourage people to stop posting on this and any other of his threads - don't feed the troll, don't encourage him. Note that all the good discussions of this thread were done while he wasn't trolling, between distant posts of him, and when he posts, we only rechew the same data over and over.

All that had to be said on the topic has been said and proven, yet the guy can't see the light. An empty bottleneck is not a problem (there is more then ennough time to process all keypress in emulation software between every emulated cycle), but an annoying troll is.

I suggest to everyone to use the ignore button on his username, too.

[Derrick Renaud]

Do you not see the "bottleneck"?

Do you?  Obviously not.  As I've said before you need to READ & Understand what has been posted in this thread.  Which you still have not done.

Raw Input does not get it's input from the Keyboard & Mouse Client or the OS Keyboard and mouse services.  It gets it directly from the USB services.  In otherwords, it gets it RAW at the USB poll rate.

Just because you take a picture of a red sky at dusk, does not mean the sky is always red.  Look out the window and see it is blue (or black at night.)

You demanded a document before you would listen to any other proof given to you, which you have since been given.  Very nice of Andy to do so, I would have never bothered looking up proof for something I know has been true for 10 years.

Now that you have been given proof, please re-read this thread and understand the other proofs given.

You refused to ever consider how windows could somehow read input directly from individual keyboards.  You still seem to be stuck thinking it is at the legacy level.  When at the level it can not individually read keyboards.

But whatever, keep enjoying the red sky in your world.

I can no longer believe that Driver-Man is doing anything but trolling.

[JustMichael]

I have heard stories of person(s) who aren't happy unless they are arguing.     I have also heard they don't care if they are right or wrong, they just want to argue.     Has anyone else heard of such person(s)?   

[Lewis Black]

If nothing else this has been a very educational thread, but I still I eagerly await the troll's flame-out.

[SavannahLion]

What exactly was the point of this thread again?

Everyone can obtain their own numbers now, after that, the point is whatever you choose it to be. You could also ask your friendly neighborhood Driver-Man to make you a better driver for that crappy USB connection of yours.

At this point, I would not install anything you wrote. I would recommend the same to anyone else looking at any of your software. You present a danger copying and pasting code you apparently do not even bother reviewing or understanding. See my next point.

Now that is a very good question!

Don't you see 7ms lag between each key would mean only about TWO KEYS per frame @60 FPS animation?

This statement is so patently ludicrous you should be kicked out of here for it. Simply playing a game with the keyboard would prove this statement wrong.

Rather than seeking education and understanding, Driver has done nothing but attempt to disprove nearly every statement that has been written here. Only when that evidence is painfully overwhelming does Driver switch his argument to another focus. Where is the value in a thread filled with nonsense counter arguments?

This thread needs to end.

[MonMotha]

Since I was scratching my head over this one, Driver-Man's "port 0x81" appears to come from the USB endpoint number.  Of course, this is not an IO port at all; it's just an identifier to separate out some of the traffic on the USB line from other traffic, but that's the only place I can think of this number coming from.  Actual IO port 0x81 would be part of the configuration registers for the 8237 DMA controller that was used on the ISA bus.  I believe those registers still exist for use with the LPC bus, but I could be wrong.  I certainly wouldn't expect applications or the OS to look for or place keyboard data there.  If you did so on a PC where those registers were active, the results could be...interesting.

Somewhat spotty compatibility with older OSes when you deviate from the "boot compatible" keyboard device.  I even have a device that should be boot compliant which works fine under 98SE and XP, but performs poorly for gaming under 2K.  Haven't tested it with Win7 yet, but I'll bet it's ok.  If it is, it will probably see the light of day eventually.  PS/2 just works, though, and I've seen a lot of folks here resort to using it when the USB side of things doesn't go their way.  That's why I tend to coax folks into using PS/2 for key input if they have the port available to them, and have never had anyone be disappointed with the performance they experience for doing so.  If nothing else, it does an excellent job for this application, and doesn't use up a USB port that could be used for something else a little less mundane.

This is a little off-topic, but it sounds like you may have some experimental data I can use (saving me the trouble of setting up one of my USB dev boards to determine it myself).  If you declare your usage as a keyboard but with "variable" (non-array) format data, 1 bit each corresponding to a pre-defined keycode, does it work in Windows or any OS for that matter?  Clearly, this is not boot protocol compatible, but I can see nothing in the HID standard that would prohibit it.  This would let you send all 104 keycodes of a standard PC keyboard using only a 13 byte report (albeit without the ability to indicate RolloverError if ghosting occured and with a potentially quite large report descriptor).

[DillonFoulds]

I think my ~9s on 100m Track and Field disproves driver-man all together, but I'm willing to try out an LPT solution to see if it actually makes any difference...

[AndyWarne]

You are not really achieving anything by sending the full information in the first 32 bytes, since you will still be sending as many of those packets as keys were pressed, just like my USB trace shows too. You are stuffing 5x32 = 160 bytes down the USB pipe just to signal 5 keys are down!?

Ok here we go again. You have missed out the captures above this which show no keys pressed, the ones which send all zeros.
So, we start with no keys pressed (all zeros). Then the next packet, 2ms later, when all keys are pressed, contains all the keys. Thats all we need to know.
But for info, now, after that another 4 packets are sent, with all the keycodes. These form no part in the process as the host already knows all 5 keys are pressed. These packets are simply repeating data already sent.
So, why are they sent? Well... the host polls the device at 2ms intervals. Usually the device will send a NAK unless it has some data to send. The trace does not show the NAKed polls as I have turned off "Disply NAKed transactions" in the view to avoid clutter.
The device has "Acked" 5 transactions and sent data. The reason I do this is just in case the host might have missed the first one. I could just send one packet every time there is a change but I send 5 (or more accurately I respond to 5 requests from the host). There is no advantage to be gained by sending only one packet so I send 5. This does not slow the process as the host gets the 5 keys in one go, on the first packet. The others are just to "make sure".

Many USB devices ACK all requests from the host and send data on all requests. I just happen to ACK 5 then stop sending unnecessarily until the next state change.

The only part you need to look at are the transaction with no keys and the one after it with 5 keys.

[saint]

Excellent post. I'm going to borrow this in the future.

This thread is still alive due to the interesting technical bits that keep coming out. When they stop this thread will be locked.

netiquette...

An "Internet troll" or "Forum Troll" or "Message Board Troll" is a person who posts outrageous message to bait people to answer. Forum Troll delights in sowing discord on the forums.  A troll is someone who inspires flaming rhetoric, someone who is purposely provoking and pulling people into flaming discussion.  Flaming discussions usually end with name calling and a flame war.
 
A classic troll is trying to make us believe that he is a genuine skeptic with no hidden agenda.  He is divisive and argumentative with need-to-be-right attitude, "searching for the truth",  flaming discussion, and sometimes insulting people or provoking people to insult him.  Troll is usually an expert in reusing the same words of its opponents and in turning it against them.

They usually have an agenda. Very few trolls come to out of pure skepticism. A Troll is generally a person who is extremely skeptical of the main forum subject.
He is generally interested to make other forum members look stupid. A troll will sometimes use insults to provoke other people to insult him. Then, he will complain to moderators of being insulted and will request that his opponents get banned from further discussion.

He (and in 90% of cases it is he) tries to start arguments and upset people.

Sometimes, Internet troll is trying to spin conflicting information, is questioning in an insincere manner, flaming discussion, insulting people, turning people against each other, harassing forum members,  ignoring warnings from forum moderators.

Trolling is a form of harassment that can take over a discussion. Well meaning defenders can create chaos by responding to trolls. The best response is to ignore it, or to report a message to a forum moderator. Moderators usually delete troll messages or block trolls.  Negative emotions stirred up by trolls leak over into other discussions. Normally affable people can become bitter after reading an angry interchange between a troll and his victims, and this can poison previously friendly interactions between long-time users.

Finally, trolls create a paranoid environment, such that a casual criticism by a new arrival can elicit a ferocious and inappropriate backlash.

When trolls are ignored they step up their attacks, desperately seeking the attention they crave. Their messages become more and more foul, and they post ever more of them.

Alternatively, they may protest that their right to free speech is being curtailed. 

Perhaps the most difficult challenge for a webmaster is deciding whether to take steps against a troll that a few people find entertaining. Some trolls do have a creative spark and have chosen to squander it on being disruptive. There is a certain perverse pleasure in watching some of them. Ultimately, though, the webmaster has to decide if the troll actually cares about putting on a good show for the regular participants, or is simply playing to an audience of one -- himself.

Next time you are on a message board and you see a post by somebody whom you think is a troll, and you feel you must reply, simply write a follow-up message entitled "Troll Alert" and type only this:

The only way to deal with trolls is to limit your reaction and not to respond to trolling messages.  It is well known that most people don't read messages that nobody responds to, while 99% of forum visitors first read the longest and the largest threads with the most answers.
 

FYI: trolling is NOT encouraging the community, in the long run it is irritating to the community members, the moderators, and only helps in encouraging people to not read interesting threads anymore. Nothing good can come out of a troll.

If the moderators don't have a good discussion with the man that talks about himself in the 3rd person, I encourage people to stop posting on this and any other of his threads - don't feed the troll, don't encourage him. Note that all the good discussions of this thread were done while he wasn't trolling, between distant posts of him, and when he posts, we only rechew the same data over and over.

All that had to be said on the topic has been said and proven, yet the guy can't see the light. An empty bottleneck is not a problem (there is more then ennough time to process all keypress in emulation software between every emulated cycle), but an annoying troll is.

I suggest to everyone to use the ignore button on his username, too.

[Driver-Man]

Don't you see 7ms lag between each key would mean only about TWO KEYS per frame @60 FPS animation?

This statement is so patently ludicrous you should be kicked out of here for it. Simply playing a game with the keyboard would prove this statement wrong.

That statement is mathematical equation -> 0.016 / 0.007 = 2.29

Forum Troll delights in sowing discord on the forums. A troll is someone who inspires flaming rhetoric, someone who is purposely provoking and pulling people into flaming discussion. Flaming discussions usually end with name calling and a flame war.

You are talking about Eris, the Greek goddess of discord, quarrel, strife and conflict. Sometimes equated with the war goddess Enyo, her name translates into Latin as Discordia. However, there are two sides to this "coin", which is beautifully put in Hesiod's "Works and Days" (700BC):

- "So, after all, there was not one kind of Strife alone, but all over the earth there are two. As for the one, a man would praise her when he came to understand her; but the other is blameworthy: and they are wholly different in nature. For one fosters evil war and battle, being cruel: her no man loves; but perforce, through the will of the deathless gods, men pay harsh Strife her honour due. But the other is the elder daughter of dark Nyx, and the son of Cronus who sits above and dwells in the aether, set her in the roots of the earth: and she is far kinder to men. She stirs up even the shiftless to toil; for a man grows eager to work when..."

[emerica]

I can't believe I read this whole thread. What is the point again?

Oh yeah...The Ipac and Keywiz work perfectly, plain and simple. So I applaud Andy, Randy, and Saint (project arcade) for making things easy for the rest of us. Thank you. 

BTW, I'm still trying to figure out what that smiley face is supposed to be in Bezerk. 

[Driver-Man]

I can't believe I read this whole thread. What is the point again?

It's over.  


What you could do now is if you can perform the simple test on your machine and show us the results.

* USBTrace 1.3.0
http://www.topshareware.com/USBTrace-transfer-42419.htm

* Passmark keyboard test
http://www.passmark.com/products/keytest.htm


TEST: Press [Q+W+E+R] at the same time, hold for a few seconds and then release them all in the same time. Then simply capture the screenshots and put it up here like we did on previous page. Can you do that please?

[JustMichael]

And what exactly are these two programs supposed to "prove"?   

[Marsupial]

And what exactly are these two programs supposed to "prove"?   

that Driver-Man is a troll.

[Driver-Man]

And what exactly are these two programs supposed to "prove"?

Statistics. Relax, it's over. Ask MonMotha to explain.
  

You have missed out the captures above this which show no keys pressed, the ones which send all zeros.

There was nothing above, that was the first set of data - 5 keys down.

YOU:



ME:

So, we start with no keys pressed (all zeros).

No, you start with 5 packets, each 32 bytes long, and each holding absolutely the same information saying 5 keys are down.

Then the next packet, 2ms later, when all keys are pressed, contains all the keys. Thats all we need to know.

No, you first send one packet with all 5 keys down, then 2ms later another one with that SAME information, and again, and again, and again. Then you release those five keys and then you again send 5 packets of 32 bytes, this time all zeros, 5 x 32 = 160 bytes just to signal 5 keys went up.

But for info, now, after that another 4 packets are sent, with all the keycodes. These form no part in the process as the host already knows all 5 keys are pressed. These packets are simply repeating data already sent. So, why are they sent? Well... the host polls the device at 2ms intervals.

No, there is no traffic going on EVERY 2ms, ONLY when you press or release a key, it is clear from the time intervals. -- You have steady 2ms intervals when you make simultaneous 5 key press, but you can then notice a longer pause when you hold down the keys before you release.

I could just send one packet every time there is a change but I send 5 (or more accurately I respond to 5 requests from the host). There is no advantage to be gained by sending only one packet so I send 5. This does not slow the process as the host gets the 5 keys in one go, on the first packet. The others are just to "make sure".

How can you control that number of packets sent? Encoder? Driver?

[JustMichael]

You have missed out the captures above this which show no keys pressed, the ones which send all zeros.

There was nothing above, that was the first set of data - 5 keys down.

I am guessing his software program is smart enough to skip the zero packets before the first keypress.  I would bet this is why we missed out on those zero packets.

So, we start with no keys pressed (all zeros).

No, you start with 5 packets, each 32 bytes long, and each holding absolutely the same information saying 5 keys are down.

He was telling us about the packets that came before the ones shown.

Then the next packet, 2ms later, when all keys are pressed, contains all the keys. Thats all we need to know.

No, you first send one packet with all 5 keys down, then 2ms later another one with that SAME information, and again, and again, and again. Then you release those five keys and then you again send 5 packets of 32 bytes, this time all zeros, 5 x 32 = 160 bytes just to signal 5 keys went up.

He sends the packet more than once to ensure that it gets there intact.  Why 5 times?  Arbitrary number I guess.

Or possibly:

2 times would be sufficient in case the first got "lost" but then you multiply that by "the rule of 2 1/2" and you get 5 times.  The "rule of 2 1/2" I refer to is a "rule" I learned a long time ago.  First you figure out how much whatever will be enough for your needs, multiply it by 2 1/2 and you're guaranteed to have enough (even under unforeseen circumstances).

But for info, now, after that another 4 packets are sent, with all the keycodes. These form no part in the process as the host already knows all 5 keys are pressed. These packets are simply repeating data already sent. So, why are they sent? Well... the host polls the device at 2ms intervals.

No, there is no traffic going on EVERY 2ms, ONLY when you press or release a key, it is clear from the time intervals. -- You have steady 2ms intervals when you make simultaneous 5 key press, but you can then notice a longer pause when you hold down the keys before you release.

Just because he only shows you part of the traffic doesn't mean the rest of the traffic doesn't exist.  AndyWarne even stated he turned off tracking of the NAK responses:

So, why are they sent? Well... the host polls the device at 2ms intervals. Usually the device will send a NAK unless it has some data to send. The trace does not show the NAKed polls as I have turned off "Disply NAKed transactions" in the view to avoid clutter.

The NAK responses are all the 2ms responses that aren't being shown.  There would be 85 NAK's responses alone between the first set of keys down and the keys up.  I think showing those 85 responses would be a big waste of space.

I could just send one packet every time there is a change but I send 5 (or more accurately I respond to 5 requests from the host). There is no advantage to be gained by sending only one packet so I send 5. This does not slow the process as the host gets the 5 keys in one go, on the first packet. The others are just to "make sure".

How can you control that number of packets sent? Encoder? Driver?

I think you are confused again and AndyWarne even clarified his statement.  There is only 1 packet being sent each time the host makes a request.  He just sends a data packet that has the keys as a response to the host's request and then resends that same data packet to the next 4 requests.

[riley454]

MY HEAD HURTS

Can someone please simplify what is the best way to connect a mame panel that plays everything from space invaders to mortal combat 4 up to a pc without the geek talk?

[CheffoJeffo]

Can someone please simplify what is the best way to connect a mame panel that plays everything from space invaders to mortal combat 4 up to a pc without the geek talk?

Sure -- RTFW.

 

[Santoro]

MY HEAD HURTS

Can someone please simplify what is the best way to connect a mame panel that plays everything from space invaders to mortal combat 4 up to a pc without the geek talk?

IMHO this is a purely academic conversation that doesn't change any of the MAME conventional wisdom as captured in the Wiki. 

[newmanfamilyvlogs]

Just for fun..  here's an unfiltered USBTrace history dump for banging on 7 keys simultaneously on a MiniPac:

http://cotmm.org/arcade/minipac_7buttons.html

Held them for a moment and smashed on a few times before the trial version's buffer filled up.

Edit:
and just for comparison sake, a trace where I rapidly press a single button:
http://cotmm.org/arcade/minipac_singlekey.html

[MonMotha]

Statistics. Relax, it's over. Ask MonMotha to explain.

I'm done arguing with you.  Leave me the heck out of this.

[AndyWarne]

How can you control that number of packets sent? Encoder? Driver?

Thats just a number I decided to use when I was writing the firmware. Some devices only ACK one packet after a state change and some ACK all packets all of the time even when there is no state change. In fact the majority of devices just ACK all host requests and send the data at the specified poll rate. This just seems unnecessary to me so I stop at 5. No point in rambling on repeating yourself over and over again.....

[MonMotha]

Thats just a number I decided to use when I was writing the firmware. Some devices only ACK one packet after a state change and some ACK all packets all of the time even when there is no state change. In fact the majority of devices just ACK all host requests and send the data at the specified poll rate. This just seems unnecessary to me so I stop at 5. No point in rambling on repeating yourself over and over again.....

Isn't this what HID IDLE is supposed to address?  Of course, IDLE seems to me like an overly complex solution to address such a simple problem.

[Driver-Man]

Just for fun..  here's an unfiltered USBTrace history dump for banging on 7 keys simultaneously on a MiniPac:

http://cotmm.org/arcade/minipac_7buttons.html

Held them for a moment and smashed on a few times before the trial version's buffer filled up.

If you could do more controlled test, so instead of "banging" and 7 buttons, try just 3 or 4 buttons, and make precise, firm simultaneous push, hold for a sec or two, and the then release them all in the same time. That should produce sufficient and more readable data, anyway here's what I conclude...

Code: [Select]

#7 0.172194 = 00 01 02 00 - Button A down
#11 0.188163 = 00 01 01 00 - Button B down
#15 0.196286 = 00 01 01 00 - Button B down
#19 0.204161 = 00 01 01 00 - Button B down
#23 0.212153 = 00 00 01 00 - Button C down / Button B up?
#27 0.220165 = 00 01 01 00 - Button B down
#31 0.228163 = 00 01 01 00 - Button B down
...holding down for 0.672 sec
#35 0.900140 = 01 00 01 00 - Button C down / Button B up?
...still holding for 0.136 sec more
#39 1.036147 = 00 00 00 00 - All buttons up
...pause
#43 1.172134 = 00 01 00 00 - Button D down / ?? up
#47 1.180117 = 00 02 00 00 - Button E down / ?? up
.
.

* 4 bytes long buffer,
looks like this is "MOUSE" type device.

* It has steady minimum latency of 8 ms,
but no constant polling rate, signals only state change

=======================================================
MAXIMUM INPUTS PER FRAME @60 FPS = 1/60 / 0.008 = 2.083

With this same pooling rate, this device could potentially do 4 x 2 = 8 inputs per frame @60fps, if it was not mouse/kbd device, or maybe if it only had different driver, who knows.

and just for comparison sake, a trace where I rapidly press a single button:
http://cotmm.org/arcade/minipac_singlekey.html

Code: [Select]

..missing 3 packets?
 #7 0.011828 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
#11 0.015812 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
#15 0.059869 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#19 0.063845 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#23 0.067835 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#27 0.071836 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#31 0.075843 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
...pause
#35 0.143824 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
#39 0.147805 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
#43 0.151797 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
#47 0.155807 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
#51 0.159800 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
...holding button down for 0.068 sec
#55 0.227818 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#59 0.231805 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#63 0.235802 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#67 0.239807 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
#71 0.243808 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - up
...pause
#75 0.291894 = 00 00 1A 00 00 00 00 00 00 00 00 00 00 00 00 00 - down
.
.


* 16 bytes long buffer, 5 packets per state change?
this is different device, or it has second controller

* It has steady minimum latency of 4 ms,
but no constant polling rate, signals only state change

=======================================================
MAXIMUM INPUTS PER FRAME @60 FPS = 1/60 / 0.004 = 4.17 ?


With this same polling rate, this device has potential to produce 4 x 16 = 64 inputs per frame, which possibly comes down to 16 inputs due to redundancy, however due to the keyboard driver, or something, this seem to be limited to only about 4 inputs per frame @60fps, minus "keys up" aka. "break codes". -- It's inconclusive, please do 3 and 4 simultaneous press test with this device too. [edit: We still have not quite established how windows drivers work and what particular method of READING the input is employed in MAME.



*** More tests & statistics...


X-Arcade trackball USB trace:



* 4 bytes long buffer,
this is "MOUSE" type device

* It has *unsteady* latency, minimum ~2-6 ms,
but no constant polling rate, signals only state change

=======================================================
MAXIMUM INPUTS PER FRAME @60 FPS = 1/60 / 0.002 = 8.33

With this same pooling rate, this device could potentially do 4 x 8 = 32 inputs per frame @60fps, if it was not mouse/kbd device, or maybe if it only had different driver, who knows.



PC GamePad (DualShock clone) USB trace:




* 8 bytes long buffer,
this is "Generic USB Joystick" device

* It has steady latency of 2 ms,
the first one that actually has constant output stream

=======================================================
MAXIMUM INPUTS PER FRAME @60 FPS = 1/60 / 0.002 x 8 = 66.7 ?

This a bit more complicated as there are two analog sticks too, and I can't really tell from this data sample if there is any redundancy there as well. In any case, this device is constantly pushing data down the USB at steady 2ms intervals and in this test I did not press any buttons at all.

[newmanfamilyvlogs]

the trackball was sending a fair bit of data that makes it harder to read. i disconnected the trackball for the following traces:

http://cotmm.org/arcade/minipac_6buttons.html
Six buttons pushed on and off, slowly and as simultaneously as I could manage

http://cotmm.org/arcade/minipac_4buttons.html
Four buttons pressed in various combination.

http://cotmm.org/arcade/minipac_twobuttons.html
Two buttons pressed in a more controlled fashion.

http://cotmm.org/arcade/minipac_twoalternate.html
Two buttons alternating as fast as I could hit them.

[Malenko]

MAXIMUM INPUTS PER FRAME @60 FPS = 1/60 / 0.008 = 2.083

When why can I jump and fire while circle strafing in a FPS game?

[Driver-Man]

MAXIMUM INPUTS PER FRAME @60 FPS = 1/60 / 0.008 = 2.083

When why can I jump and fire while circle strafing in a FPS game?

Holding a third key will not impact the two other keys you are "tapping", you will still be able to report both jump and fire in the same frame. However, if you start from complete still, and then press all three in the same time, then in the 1st frame you will do two of those three actions, and in the very next frame program will pull the 3rd one from the buffer (even if you release them all by this time) and so this would be impossible to notice... but, in Donkey Kong, try to stand still and then *TAP* "jump+arrow key" and see if you can do it at all (jump sideways).


I have to fix some numbers in my previous post...

[Malenko]

Holding a third key will not impact the two other keys you are "tapping", you will still be able to report both jump and fire in the same frame. However, if you start from complete still, and then press all three in the same time, then in the 1st frame you will do two of those three actions, and in the very next frame program will pull the 3rd one from the buffer (even if you release them all by this time) and so this would be impossible to notice... but, in Donkey Kong, try to stand still and then *TAP* "jump+arrow key" and see if you can do it at all (jump sideways).


I have to fix some numbers in my previous post...

but I do that all the time, turn face to barrel standing jump backwards...... in street fight I'll hold tap D+F+medium kick with chun li all the time, in bad dudes I tap up+forward+jump+atack to spin kick.........

[Driver-Man]

Ok, can you make "SIMULTANEOUS 3 BUTTON TEST" and "SIMULTANEOUS 4 BUTTON TEST", then put up screenshot of the USB trace here? [Edit: two tests, both can be done in one session]

[newmanfamilyvlogs]

I don't follow 'simultaneous 3 and 4 button'. You mean you want seven buttons simultaneously?

[Driver-Man]

First do one, then the other test,  you can do it both in one session.

1. Start session

2. Press THREE buttons in the same time
...hold ~2 seconds

3. Release all three buttons in the same time
...wait ~5 seconds

4. Press FOUR buttons in the same time
...hold ~2 seconds

5. Release all four buttons in the same time

6. Capture the screen and upload the image here


* Maybe also apply filters, so to only show "IN" packets with "DATA".

[Marsupial]

I tought this topic was over?


Oh, that's right...

it won't be over until its either locked, or Driver-Man is revoked rights to post into it... I almost forgot.


edit: quote:

It's over. 

[Driver-Man]

Argument is over. Conclusion is - "it depends".

No one is arguing anymore, we are simply sharing information now. 

[newmanfamilyvlogs]

Filtered of three down, then up, then four down, then up.

Then successively pressing several keys and remaining down, then all up.

Filtered to only data in.
http://cotmm.org/arcade/minipac_3then4.html

[Smeghead]

WTF is an LPT port any more these days anyway   

[JustMichael]

Driver-Man,
I am curious as to why you seem to think that Mame only gets 1 key for each time a USB device gets polled even though as you have already seen, USB devices like the I-PAC transmit all their keypresses in one data packet?

[CheffoJeffo]

Argument is over. Conclusion is - "it depends".

No.

The conclusion is that the USB (EDIT) interfaces available from Ultimarc and Groovy Game Gear work fine, despite the fact that they are not LPT-based.

Everybody who has a cab and has played two player simultaneous games has hit at least 6 keys simultaneously, with the SF and 4-player crews hitting more.

If there were a problem, then I am certain that they, or at least kowal, would have already raised the issue.

The particular topic that you are pursuing has been beaten to death eleventy12! times before, but you want somebody to teach you about it. Read Tiger-Heli's encoder tome. Read the multitude of threads here on the topic (we have had some particularly juicy ones on the topic of USB, PS/2, keyboard and gamepads).

Stop being a twerp and sucking the life out of things because you don't understand.

PS - 60-in-1 boards are illegal!

[newmanfamilyvlogs]

Stop being a twerp and sucking the life out of things because you don't understand.

PS - 60-in-1 boards are illegal!

Dammit, I just laughed out loud in my office and everyone looked at me. Thanks 

[CheffoJeffo]

.

[JustMichael]

Stop being a twerp and sucking the life out of things because you don't understand.

PS - 60-in-1 boards are illegal!

 

[AndyWarne]

Driver-Man,
I am curious as to why you seem to think that Mame only gets 1 key for each time a USB device gets polled even though as you have already seen, USB devices like the I-PAC transmit all their keypresses in one data packet?

I am sure that he does understand that. He is just wasting everyones time by asking for more data captures etc for no reason. The trouble is, people are providing them so this could go on for ever....

[newmanfamilyvlogs]

The more time he's chewing through those data spews, the less time he's posting elsewhere, rite?

[CheffoJeffo]

Driver-man is a troll with limited, and dated, technical knowledge, trying, by his own admission, to ---fudgesicle--- with people ... just like the last incarnation of the Belligerent Kool-Aid Man (props to CWT for the moniker).

Just wait, soon he'll start talking about what the game programmers meant to do with their interfaces ... 

[saint]

Is the consensus that the good technical info in this thread has come to an end?

[JustMichael]

+1
I think anymore would be and we would be going against  

Thread Hijack!!!

Why this smiley:
 
I also see a   (this one I understand but not the other one)

[SavannahLion]

Is the consensus that the good technical info in this thread has come to an end?

Wait! I want to know what's with the Belligerent Kool-Aid Man thing. I must know!

[Smeghead]

I think we all need to eat some cheesecake together and make up

[Marsupial]

Is the consensus that the good technical info in this thread has come to an end?

a while ago?

the thread won't be over until one of two things happens...


1- it gets locked
2- somehow Driver-Man's rights to post into it are revoked

I am mainly following this like people follow soap opera at this point.

[Driver-Man]

Filtered of three down, then up, then four down, then up.

Then successively pressing several keys and remaining down, then all up.

Filtered to only data in.
http://cotmm.org/arcade/minipac_3then4.html

Code: [Select]

#1   3.282165 = 00 00 14 00 00 00 00 00 00 00 00 00 00 00 00 00
 #3   3.286148 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
 #5   3.290140 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
 #7   3.294151 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
 #9   3.298151 = 00 00 14 1A 16 00 00 00 00 00 00 00 00 00 00 00 <-5x4= 0.020s
#11   3.302147 = 00 00 14 1A 16 00 00 00 00 00 00 00 00 00 00 00
#13   3.306163 = 00 00 14 1A 16 00 00 00 00 00 00 00 00 00 00 00
#15   3.310146 = 00 00 14 1A 16 00 00 00 00 00 00 00 00 00 00 00
#17   3.314155 = 00 00 14 1A 16 00 00 00 00 00 00 00 00 00 00 00 - 9 / 5
...hold 6.181 seconds

3 keys per 0.020 seconds ~ 2 keys per frame @60fps

Code: [Select]

#19   9.494732 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
#21   9.498698 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
#23   9.502704 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
#25   9.506708 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
#27   9.510712 = 00 00 14 1A 00 00 00 00 00 00 00 00 00 00 00 00
#29   9.514709 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <-6x4= 0.024s
#31   9.518709 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#33   9.522714 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#35   9.526675 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#37   9.530670 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 10 / 5
...all up, wait 8.661 seconds

3 keys per 0.024 seconds ~ 2 keys per frame @60fps

Code: [Select]

#39  18.191523 = 00 00 0E 00 00 00 00 00 00 00 00 00 00 00 00 00
#41  18.195496 = 00 00 0E 00 00 00 00 00 00 00 00 00 00 00 00 00
#43  18.199501 = 00 00 0E 00 00 00 00 00 00 00 00 00 00 00 00 00
#45  18.203496 = 00 00 0E 00 00 00 00 00 00 00 00 00 00 00 00 00
#47  18.207500 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#49  18.211493 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#51  18.215498 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#53  18.219495 = 00 00 0E 0C 04 00 00 00 00 00 00 00 00 00 00 00 <-8x4= 0.032s
#55  18.223494 = 00 00 0E 0C 04 00 00 00 00 00 00 00 00 00 00 00
#57  18.227520 = 00 00 0E 0C 04 00 00 00 00 00 00 00 00 00 00 00
#59  18.231496 = 00 00 0E 0C 04 00 00 00 00 00 00 00 00 00 00 00
#61  18.235490 = 00 00 0E 0C 04 00 00 00 00 00 00 00 00 00 00 00 - 12 / 5
...hold 5.448 seconds

4 keys per 0.032 seconds ~ 2 keys per frame @60fps  -- Information is only in 3 bytes, so if you did press 4 keys here, some of them were probably ctrl, alt and/or shift, they all can most likely be stored in one byte

Code: [Select]

#63  23.684058 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#65  23.688012 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#67  23.691993 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#69  23.695997 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#71  23.699996 = 00 00 0E 0C 00 00 00 00 00 00 00 00 00 00 00 00
#73  23.703991 = 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 00 00
#75  23.707999 = 00 00 00 0C 00 00 00 00 00 00 00 00 00 00 00 00
#77  23.711987 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <-8x4= 0.032s
#79  23.715984 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#81  23.720002 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#83  23.723984 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
#85  23.728011 = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 - 12 /5
...all up, wait 16.538 seconds

4 keys per 0.032 seconds ~ 2 keys per frame @60fps

=====================================================


CONCLUSION REACHED:
- With the current polling rate this device has maximum output of 2 keys per frame @60fps. This "bottleneck" is completely unrelated to how data is handled on arrival, from here on it can only get worse.

Driver-Man, I am curious as to why you seem to think that Mame only gets 1 key for each time a USB device gets polled even though as you have already seen, USB devices like the I-PAC transmit all their key presses in one data packet?

That's the least of your concerns actually, there are more important interrupts and lags before the data even comes to that point, look at the USB trace. Required information is simply not arriving at sufficient rate, nothing much MAME can do about it, except buffer and extrapolate/interpolate, just like with networking.

1- it gets locked
2- somehow Driver-Man's rights to post into it are revoked

There are, of course, those who do not want us to speak. I suspect even now orders are being shouted into telephones and men with guns will soon be on their way. Why? Because while the truncheon may be used in lieu of conversation, words will always retain their power. Words offer the means to meaning and for those who will listen, the enunciation of truth...

Cruelty and injustice, intolerance and oppression. And where once you had the freedom to object, to think and speak as you saw fit, you now have censors and systems of surveillance, coercing your conformity and soliciting your submission. How did this happen? Who's to blame? Well certainly there are those who are more responsible than others, and they will be held accountable. But again, truth be told... if you're looking for the guilty, you need only look into a mirror.

Is the consensus that the good technical info in this thread has come to an end?

E pur si muove.

[JustMichael]

Driver-Man has successfully proved he knows almost nothing about USB devices (I think he knows how to plug them in...).  With more jibberish like this from Driver-Man I will gladly lock this thread.

[saint]

There are, of course, those who do not want us to speak. I suspect even now orders are being shouted into telephones and men with guns will soon be on their way. Why? Because while the truncheon may be used in lieu of conversation, words will always retain their power. Words offer the means to meaning and for those who will listen, the enunciation of truth...

Cruelty and injustice, intolerance and oppression. And where once you had the freedom to object, to think and speak as you saw fit, you now have censors and systems of surveillance, coercing your conformity and soliciting your submission. How did this happen? Who's to blame? Well certainly there are those who are more responsible than others, and they will be held accountable. But again, truth be told... if you're looking for the guilty, you need only look into a mirror.

Is the consensus that the good technical info in this thread has come to an end?

E pur si muove.

You're not coming across as clever, or educated, or philosophical, or as a martyr -- you're just coming across as annoying. Being annoying is not a virtue. It's just annoying. Any value you attempt to bring to the community is lost in the fact that you're just annoying. Being annoying may bring you some intangible internal benefits and warm fuzzies, but it won't get you far in life because... it's annoying.

I knew Galileo, and you sir are no Galileo.