Main > Main Forum

USB vs PS/2 vs COM vs LPT

Pages: << < (16/43) > >>

SavannahLion:


--- Quote from: Driver-Man on September 19, 2010, 09:39:16 pm ---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.

--- End quote ---


--- Quote ---Only LPT can communicate *instantaneous* state of the port at any given time and as often as the CPU clock ticks, 8 bits at the time, in parallel, which means you can read the state of 16 buttons in just two instructions.

--- End quote ---


--- Quote from: Driver-Man on September 20, 2010, 08:45:02 am ---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.

--- End quote ---


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

--- End quote ---

Then on page two you wrote:


--- Quote from: Driver-Man on September 23, 2010, 02:33:56 am ---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.

--- End quote ---

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:


--- Quote from: Driver-Man on September 23, 2010, 02:33:56 am ---
--- Quote ---For those that have have suffered through this thread this far please queue

--- End quote ---

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.

--- End quote ---

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.


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

--- End quote ---

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:


--- Quote from: Driver-Man on September 23, 2010, 06:36:02 am ---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.


--- End quote ---

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:


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

--- End quote ---

I agree.



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

--- End quote ---

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

Backwards compatibility, friend or foe?


--- Code: ---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

--- End code ---

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?




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

--- End quote ---

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?



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

--- End quote ---

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.




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

--- End quote ---

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:


--- Quote from: Driver-Man on September 23, 2010, 06:46:19 pm ---...It's Driver-Man's instinct, senses tingling and such....
--- End quote ---

You're a troll. 

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

Pages: << < (16/43) > >>

Go to full version