Main > Main Forum

USB vs PS/2 vs COM vs LPT

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

SavannahLion:


--- Quote from: Driver-Man on September 24, 2010, 03:16:10 am ---
--- Code: ---void main(){
  while(inportb (0x60)!=1)
    printf("\nKey: %i", inportb(0x60));
}

--- End code ---
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.

--- End quote ---

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.  :dunno

Driver-Man:


--- Quote from: SavannahLion ---Virtualization. NTVDM probably. You'll need to be specific about what compiler you're using. inportb is actually a mnemonic in some compilers.

--- End quote ---

That was compiled with Borland Turbo C++ 3.0 (1990). Here is assembler version:


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

--- End code ---
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:


--- Quote from: Hoopz on September 20, 2010, 09:34:00 am ---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).

--- End quote ---

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

 :laugh:

Oh, I forgot... As for no diodes when multiplexing inputs,  I say  :dizzy:.  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.

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

Go to full version