USB vs PS/2 vs COM vs LPT

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