| Main > Main Forum |
| USB vs PS/2 vs COM vs LPT |
| << < (29/43) > >> |
| MonMotha:
--- Quote from: Driver-Man on September 25, 2010, 06:32:21 am --- --- Quote from: MonMotha ---Windows (and Linux, and any other "real" OS) kick the BIOS emulation to the curb (turn it off). --- End quote --- According to what? Show me. --- End quote --- Did you read the rest of the post? I ran a native Win32 application that read port 0x60. I got PS/2 data, but not USB data. If emulation of USB keyboards via port 0x60 were present, I would have gotten USB keyboard data via that interface, as well, but I didn't. --- Quote from: Driver-Man on September 25, 2010, 06:32:21 am --- --- Quote ---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. --- End quote --- No source code, no binary downloads, can we not try it out? --- End quote --- Oh wait, you DID read that part! You just conveniently ignored it above. As to where the source is, I already posted it previously in this thread. It's the same code you built for DOS just with inportb and outportb defined since Windows doesn't include them anymore. It's the same program that crashes unless you take special consideration (e.g. using "userport") to unblock raw IO port access. Userport also comes with source code, if you really want to read it. --- Quote from: Driver-Man on September 25, 2010, 06:32:21 am --- --- Quote ---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. --- End quote --- 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. --- End quote --- OpenHCI has nothing to do with this. Heck, if you're on an Intel motherboard, you probably don't even have an OCHI controller. You probably have a UHCI one. We know that NT runs DOS applications inside NTVDM. DOS applications can't run directly on NT, so it has to. We know that NTVDM emulates legacy BIOS interfaces. There are lots of articles all over the place that describe this, including Microsoft's website. Try some of these (3 links). The last one is especially informative, though it's also the oldest, referring to NT 4.0. The other articles confirm that this still applies to Win2k, upon which XP is based. This KnowledgeBase article shows that it still applies to WinXP, too. Just search that last page link of the 3 for NTVDM (second hit), and you'll find this little tidbit: --- Quote from: Microsoft Technet ---MS-DOS-based applications run on Windows NT 4.0 in a process called an NT Virtual DOS Machine (NTVDM). NTVDM is a 32-bit Windows application that simulates an Intel 486 computer running MS-DOS. --- End quote --- --- Quote from: Microsoft Technet ---To run MS-DOS-based applications, the NTVDM creates a virtual computer including support for: •Intel x86 instructions, provided by the Instruction Execution Unit •Read-only memory basic input and output (ROM BIOS) interrupt services, provided by the MS-DOS emulation module •MS-DOS Interrupt 21 services, provided by the MS-DOS emulation module •Virtual hardware for devices, such as the screen and keyboard, provided by Virtual Device Drivers --- End quote --- (Emphasis mine) In other words: --- Quote from: MonMotha on September 25, 2010, 03:15:11 am ---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. --- End quote --- (Isn't it handy when you can quote yourself?) Basically, any DOS application you run on modern (meaning less than 10 years old) Windows is running inside an emulation layer. This means that attempting to extrapolate basic underlying system behavior from the behavior of a DOS application running on said modern Windows OS will give misleading and even irrelevant results. --- Quote from: Driver-Man on September 25, 2010, 08:49:59 pm ---Is this Microsoft page outdated and simply wrong: http://www.microsoft.com/whdc/archive/usbhost.mspx --- End quote --- Did you read that page? That page basically says that, since the BIOS supports legacy emulation of USB devices upon startup and this would conflict with Windows talking to USB devices directly, Windows has to kick it out of the way so that it can talk to USB devices directly. Look at Figure 1 and read the section "Operating System Takes Control of the OHCI Host Controller" (there is also one detailed for UHCI controllers). Yeah, you're trolling. I'd just ignore you, but I'd be afraid that others on here would believe the crap you're spewing and make poor decisions based on it. --- Quote from: Jack Burton on September 25, 2010, 01:08:50 pm ---So my question to RandyT, Mon Mothma, Andy, etc. Is there any real added benefit to using Ps/2, Serial, or parallel port connections? From a stand point of the standards themselves, and not whatever factors are involved in the PC they are connected to. In an ideal environment are there any differences in performance between USB, PS/2, Serial, NES, gameport, and parallel port connections? If it is even a small advantage I'm completely willing to go the extra length for it. Convenience is not important to me. My main emulation machine has an LPT port on it and I'm willing to build a custom controller for it (diodes, resistors and all) if it will get me just a little advantage. --- End quote --- Not really. The parallel port is handy if you don't want to buy anything, are willing to do a fair bit of software hackery, and only need up to 13 inputs. Beyond that the matrixing/multiplexing required makes it inferior to dedicated, multi-input encoders in terms of either complexity or having ghosting issues. While it's easy to make this a very non-laggy interface, you have to possibly worry about switch bounce and such with directly connected inputs, and a properly designed USB interface has no effective lag by providing data faster than the PC software needs it. The serial port has no real usage in this application. It requires software hackery like the parallel port would while being much slower than USB and still requiring a "smart" outboard device to communicate. It would only really be useful if you had a microcontroller with a UART (common) but not a USB interface (these are less common and more complex) that you were already using and wanted to interface to your PC. PS/2 ports offer no real advantages over a properly designed USB encoder. I'd only use it if USB was unavailable or I was building my own quick-and-dirty hardware and didn't want to deal with the hardware/software complexity of USB. USB is readily available and, when applied properly, has no real downsides to its use with gaming and emulation. It's one of the more complex solutions to implement for the designer, but it provides plug-and-play ease for the user once the design has been done. |
| Jack Burton:
Thank you mon mothma. Reading this: http://en.wikipedia.org/wiki/Game_port I was struck by a few pieces of information. "Unlike most other joystick connectors (and controllers) during the early days of home computing and game consoles, the game port is actually analog rather than digital, relying on some form of ADC to interpret joystick movements. " "While other joystick standards (such as Atari or NES joysticks) are very easy and straightforward for programmers to use, the game port requires careful programming and well-timed software interrupt triggering to read an input. This of course caused performance issues as reading the game port took a notable amount of CPU time, especially compared to systems with a 'normal' digital (TTL) joystick port." I don't know if this would actually make a practical difference, but it does sound like my faith in the gameport as a low lag connection was misplaced. Looks like it needs to be read just like USB does. It is not the same as an NES controller. Of course in practical use I'm guessing the amount of processing time required is trivial for gameport just like it is for USB. Right? |
| MonMotha:
--- Quote from: Jack Burton on September 25, 2010, 11:37:51 pm ---Thank you mon mothma. Reading this: http://en.wikipedia.org/wiki/Game_port I was struck by a few pieces of information. "Unlike most other joystick connectors (and controllers) during the early days of home computing and game consoles, the game port is actually analog rather than digital, relying on some form of ADC to interpret joystick movements. " "While other joystick standards (such as Atari or NES joysticks) are very easy and straightforward for programmers to use, the game port requires careful programming and well-timed software interrupt triggering to read an input. This of course caused performance issues as reading the game port took a notable amount of CPU time, especially compared to systems with a 'normal' digital (TTL) joystick port." I don't know if this would actually make a practical difference, but it does sound like my faith in the gameport as a low lag connection was misplaced. Looks like it needs to be read just like USB does. It is not the same as an NES controller. Of course in practical use I'm guessing the amount of processing time required is trivial for gameport just like it is for USB. Right? --- End quote --- The PC game port kinda sucks, yeah. It consists of a half-assed ADC for the joystick axes and a few digital inputs for buttons. There's no IRQ available; the CPU has to poll it, and the A/D conversion timing is, historically, at least, largely CPU driven (hence that article complaining about timing issues). The as for interfacing arcade game controls, there's 4 button inputs available, and they can be talked to in a similar way to the PC parallel port. The NES controller is basically a bunch of buttons hooked up to a parallel load, serial out shift register (74xx166 style). The NES would strobe the load/latch input, then shift out all the bits serially. Effectively, this forms something like a SPI interface (and I've seen the SPI port of a microcontroller used to talk to it). Since the number of bits is low (8 buttons: 4 for the D-Pad, A, B, Start, Select), even a moderate clock frequency of e.g. 83.33kHz (used by the NES) results in a maximum usable poll rate of 9.26kHz (83.33k/9 - 9 to include an extra bit time to latch the data) if you polled it continuously. This document describes the protocol in some detail. This type of serial transfer can also be bit-banged pretty easily on a parallel port, and I know there are lots of examples out there. The CPU overhead required isn't too outrageous, though it probably requires busy loops (wasted CPU time) since it's not worth yielding CPU time during the period between clock edges on most OSes (even "highly interactive" Linux configurations only preempt 1000 times/sec). Many other game console controllers work similarly. The Playstation Dualshock (2), for example, is basically a smarter version of that. The host can perform serial transfers to manipulate what mode the controller is in or ask for controller state data. If the host requests controller state data, the controller responds with a bunch of bits that map to the various buttons as well as some wider bit fields that represent the position of the analog sticks. For the Dualshock 2 with analog buttons, the buttons are more than a single bit; they are instead several bits that represent a number related to how hard the user is pressing the button. Bit banged parallel port interfaces for dualshocks are also pretty common. When talking to a dedicated microcontroller or similar, a SPI controller or USART can be used. The Neo-Geo AES and Atari sticks are some of the few that really are just a bunch of totally unmultiplexed digital inputs on a connector. Since that was also how the arcade controls worked, and MVS and AES hardware was virtually identical, this makes some sense for the Neo-Geo, and Atari sticks just don't have very many inputs. |
| Driver-Man:
--- Quote from: MonMotha ---That page basically says that, since the BIOS supports legacy emulation of USB devices upon startup and this would conflict with Windows talking to USB devices directly, Windows has to kick it out of the way so that it can talk to USB devices directly. Look at Figure 1 and read the section "Operating System Takes Control of the OHCI Host Controller" (there is also one detailed for UHCI controllers). --- End quote --- No. That is not really about Windows, but any OS. It says that OS has the choice to use BIOS drivers, if present. It also says PS/2 emulation is within SMM, which is transparent to the operating system and application software, and so this functionality stays as a part of whatever higher-level operation is wrapped around it. --- Quote ---Basically, any DOS application you run on modern (meaning less than 10 years old) Windows is running inside an emulation layer. This means that attempting to extrapolate basic underlying system behavior from the behavior of a DOS application running on said modern Windows OS will give misleading and even irrelevant results. --- End quote --- How about this "Passmark keyboard test" from www.passmark.com, AndyWarne was talking about? I get minimum of 7-8 ms lag between each scan code sent with USB keyboard. With PS/2 keyboard this lag is 4-5 ms. That comes down to about two keys per frame @ 60FPS. And so, I was right after all, at least as far as my own computer goes. -- I also tried several "USB sniffer" programs, and according to this little investigation I see key codes are always transmitted one by one, and there are all sorts of lags and two-way communication going on in between each packet. Anyway, do you accept 'Passmark keyboard test' as "benchmark" program to settle this argument? --- Quote ---The parallel port is handy if you don't want to buy anything, are willing to do a fair bit of software hackery, and only need up to 13 inputs. Beyond that the matrixing/multiplexing required makes it inferior to dedicated, multi-input encoders in terms of either complexity or having ghosting issues. --- End quote --- - "are willing to do a fair bit of software hackery," Not true, many emulators have this driver built in, plus there are "joystick" OS specific drivers for Windows, Linux and DOS. This is mature and very well tested interface enjoyed by many people who know about it, for the last 8 years or more. - "and only need up to 13 inputs." TGXLPT sets the maximum number of inputs, 9x7 = 63. - "Beyond that the matrixing/multiplexing required makes..." 8 bits at the time, gathering 24 inputs in just three instructions... Did you not say that is exactly how arcade games originally did it? |
| AndyWarne:
--- Quote from: Driver-Man on September 25, 2010, 08:49:59 pm --- False. Turning BIOS legacy support off will only disable hardware level PS/2 emulation, and so Windows will use its own emulation driver, that will be doing the SAME THING - interfacing with keyboard controller and port 0x60. Is this Microsoft page outdated and simply wrong: http://www.microsoft.com/whdc/archive/usbhost.mspx --- End quote --- Its outdated. --- Quote ---XP does NOT use the port 60 route. Anything on the web which states otherwise is either outdated or simply wrong. XP does NOT use the port 60 route. Can you show us anything on the web that says so? Or perhaps that's some mysterious unspoken truth everyone is supposed to believe without questioning? --- End quote --- OK here you go: http://www.microsoft.com/whdc/archive/usbcompat.mspx?pf=true#E2C Also go into Device Manager and look at a HID keyboard, and Driver Details. There you will find i8042prt.sys (the emulation driver) is not there. |
| Navigation |
| Message Index |
| Next page |
| Previous page |