Main > Main Forum
USB vs PS/2 vs COM vs LPT
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. :dunno
In the end, let's see some price points that this will cost!
DJ_Izumi:
--- Quote from: DillonFoulds on September 24, 2010, 10:33:47 pm ---In the end, let's see some price points that this will cost!
--- End quote ---
Don't forget necessary time to invest and what'd probably be a lot of trouble shooting.
Driver-Man:
--- Quote from: DillonFoulds ---I still don't know what the point of this whole thread is.
--- End quote ---
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!
--- Quote from: JustMichael ---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.
--- End quote ---
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?
--- Quote ---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.
--- End quote ---
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?
--- Quote ---The USB specification already determines the maximum rate that a USB keyboard controller can supply scan codes.
--- End quote ---
Nonsense. By the way, you are contradicting MonMotha, he said USB does not use keyboard controller at all.
--- Quote ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version