Main > Main Forum
USB vs PS/2 vs COM vs LPT
mrtuesday42:
just my .02$
i dont understand enough of this at the low level to give a truly valid opinion, but as far as an outsider reading this guys first post/thread start it SCREAMED troll at me. just everything about it was troll and not an actual conversation starter on the topic. just my two cents though.
Osirus23:
--- Quote from: mrtuesday42 on September 20, 2010, 05:31:38 pm ---just my .02$
i dont understand enough of this at the low level to give a truly valid opinion, but as far as an outsider reading this guys first post/thread start it SCREAMED troll at me. just everything about it was troll and not an actual conversation starter on the topic. just my two cents though.
--- End quote ---
Same here, I'm used to seeing this kind of nonsense from countless troll posts at avsforum.
Driver-Man:
--- Quote from: RandyT ---The PS/2 keyboard port can operate at around 30,000 bits per second.
If you do the math, you will see that 30,000 / 11 = 2727 pieces of keyboard data per second are possible. Divide that by 60, and you get up to 45 pieces of keyboard data per frame.
--- End quote ---
PS/2 = 30,000 bits per second/11 = 45 inputs per frame @ 60 FPS
PS/2 turns out to be better than USB? That sounds reasonable from where I stand, but Wikipedia says PS/2 is at 10 to 16 kHz. -- Can you confirm whether is that supposed to mean 16,000 bits per second, bytes per second, or scan codes per second? -- According to Wikipedia numbers, I think that comes down to about 24 inputs per frame, which IS good.
--- Quote ---So your scenarios just don't hold any water, and the "mario example" is just absurd.
--- End quote ---
Your conclusion is based on what numbers? I was talking about USB and numbers given by JustMichael. You did it for PS/2, and that was good, now do the same for USB if you want to be talking about the same thing as I was.
USB = ?? bits per second/11 = ?? inputs per frame @ 60 FPS
--- Quote ---If the events are provided in parallel, as a packet of keyboard data is over USB, there is no guarantee as to the sequence the data will be acted upon.
--- End quote ---
What did you say? Kbd data is provided in parallel over USB?
If you were talking about LPT... the sequence is defined by animation frames, that's the resolution, and as long as you poll the state every frame you are not missing any information - the "sequence" does not exist in-between the frames, you read input all at once, and the sequence you get when you look at the collection of some of those frames. That is exactly what makes SIMULTANEOUS press of 12 buttons, during only one frame, possible.
--- Quote ---For instance, our GP-Wiz controller can report the state of all 40 inputs in an 8ms time frame. In other words, it can do it twice for every frame of a 60hz sampling game, which is 200% of what is required.
--- End quote ---
At what maximum rate KeyWiz generates key codes, again? Please express that in bits per second as you did for PS/2, or scan codes per second. -- Anyway, it seems the numbers for PS/2 and your KeyWiz pass the Driver-Man's test of excellence, congratulations. Although, I do not see why would you not start making 'txglpt' adapters as well.
--- Quote ---And then there's compatibility. If the game supports the interface, then great. What if it doesn't?
--- End quote ---
What game? MAME/MESS supports this interface, which means almost every game you would ever wanna play on your arcade cabinet supports it.
Are you talking about DOS games? Driver-Man already made that:
http://forum.arcadecontrols.com/index.php?topic=105222.0
--- Quote ---The drivers out there don't seem to be available for Windows 7, and work has been discontinued.
--- End quote ---
What drivers? I'm talking about MAME, what games are you talking about?
Are you saying MAME support for "tgxlpt1" does not work under Windows 7? I would not know anything about it, I do not use MAME version later than v.58, nor OS later than XP. -- If there are indeed no drivers then I'll write the driver, will you test it?
--- Quote ---If you are indeed the "driver man", then put your money where your mouth is and develop a cross platform driver that integrates perfectly with the current operating systems....
--- End quote ---
--- Code: --- int port = 0x378; // LPT1
int i,j,k,l,m;
outportb(port+2,0x04); // 4 extra inputs
outportb(port,0xFF); // all out high
m=0xFE; // start with 1st js
for (j=0;j<7;j++) // js1-7
{
outportb (port,m); // active js to low
m<<=1; // shift the low signal
m=m | 0x1;
k=inportb(port+1);
l=inportb(port+2);
if (!(k & 16)) printf("up "); // Select B-4
if (!(k & 32)) printf("down "); // PaperEnd B5
if (!(k & 64)) printf("left "); // -ACK B6
if ((k & 128)) printf("right "); // Busy B7
if (!(k & 8)) printf("F1 "); // -Error B3
if ((l & 2)) printf("F2 "); // -AutoFeed C1
if (!(l & 4)) printf("F3 "); // -SelectIn C2
if ((l & 8)) printf("F4 "); // Init C3
if ((l & 1)) printf("F5 "); // -Strobe C0
}
--- End code ---
http://www2.burg-halle.de/~schwenke/parport.html
By the way I'm not that guy, I just found it while I was looking for the parallel interface that uses most arcade-like wiring and can support the most inputs. Tgxlpt sets the maximum number of inputs in MAME and in many other emulators that supports it. Anything that runs with Allegro library too. Anything on Linux as well.
--- Quote ---... and can output keyboard events properly, even with the RAW input model, because this is what the keyboard devices do.
--- End quote ---
Why in the world would you want to output keyboard events? What games and emulators are you talking about? MAME/MESS already have the driver built-in, and the best part about it is that you can forget all the 'scan codes' crap. Funny thing though, I actually did that already for use with NO$CPC emulator for Amstrad CPC, which does not have txglpt1 support built it. You can find download links here: http://forum.arcadecontrols.com/index.php?topic=105222.0
Driver-Man:
--- Quote from: AndyWarne on September 20, 2010, 04:49:42 pm ---
--- Quote from: JustMichael on September 20, 2010, 03:37:34 pm ---
USB does not transmit just 1 key each time it is polled like you are trying to suggest. The USB device transmits a block of data each time it is asked. The computer takes the USB data and determines which keys are being press and tells Mame all the keys that are being pressed each time Mame asks.
--- End quote ---
Spot on. Furthermore the I-PAC is polled at 500Hz . There is just no issue here.
The way in which all pressed keys are sent, in virtually no time (12 Mbps), as a packet, and processed as such on the PC is the closest you will get to a game board.
--- End quote ---
You mean USB is polled at 500Hz. Do we have some reference to confirm that number?
I'm asking at what maximum rate can I-PAC *generate* scan codes, how many per second?
Driver-Man:
--- Quote from: RandyT ---Without the pull-up resistors, the method will not work at all on parallel ports where they weren't built in. Some were, and some weren't.
--- End quote ---
I suppose all 5 of my computers had them built in.
How do you know about it? Can you back that up, would there be some article on the Internet about it?
--- Quote ---Now consider the following, where the green dots are switch closures;
Without diodes, what do you think happens at junction [ACK, Data 0] ? If you don't know, you have no place in this community to direct others as to what is and isn't the best way to interface their controls.
--- End quote ---
I said I tested this on 5 computers, pay attention.
And what if it is you "who does not know", my human friend?
I know exactly what happens, take a look at the driver source code.
------------
No place in community? ...Driver-Man, friend or foe?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version