USB vs PS/2 vs COM vs LPT

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