Main > Main Forum
USB vs PS/2 vs COM vs LPT
CheffoJeffo:
As much as I hate to admit it ... Hoopz was right ...
Derrick Renaud:
I guess I could add one last thing.
There is a difference between using a hacked USB keyboard, and a good USB input board that sends keyboard data.
A basic PC keyboard is not designed for multiple button presses as needed by arcade enthusiasts. Whereas the input boards have been designed with that in mind.
MonMotha:
So, I built this using Visual Studio 2005 as a Win32 console application. inportb is no longer defined by Windows (and hasn't been for a while), so I had to define it myself. Here's the code I used:
--- Code: ---#include <stdio.h>
char inportb(void *portid)
{
char value;
__asm mov edx, portid
__asm in al, dx
__asm mov value, al
return value;
}
void outportb(void *portid, char value)
{
__asm mov edx, portid
__asm mov al, value
__asm out dx, al
}
int main(int argc, char* argv[])
{
printf("Keyboard Port Read Test\n");
while(inportb (0x60)!=1)
printf("\nKey: %i", inportb(0x60));
}
--- End code ---
Lo and behold, when I run it, it...crashes. Right on that "in" instruction. For security, system stability, and a whole host of other reasons, Windows NT won't let a userspace application talk directly to the keyboard controller (amongst lots of things).
I'm guessing you built yours as a DOS application. When you run a DOS application on NT, it actually runs inside an emulation/compatibility layer known as NTVDM. Quoting the wikipedia article:
(Edit: Given that you used a 20 year old C compiler that predates the existence of NT, I'm sure you built yours as a DOS application)
--- Quote ---When a DOS program running inside a VDM needs to access a peripheral, Windows will either allow this directly (rarely), or will present the DOS program with a Virtual Device Driver which emulates the hardware using operating system functions. A VDM will systematically have emulations for the Intel 8259A interrupt controllers, the 8254 timer chips, the 8237 DMA, etc.
--- End quote ---
This emulation would also include the keyboard controller.
Let's attempt to confirm these findings:
I also have a truly ancient copy of Masm laying around. It generates DOS executables (really, the only difference is the linker and some header stuff that tells Windows what environment to run it in). I built your assembly version using Masm, and it worked. This is unsurprising. Since it's a DOS executable, not a native Win32 executable, NT happily runs it inside NTVDM and emulates the keyboard controller for you. If I had an old DOS C compiler, I could do the same thing with the C version.
Win9x does not have NTVDM. Since Win9x is really just a fancy shell on top of DOS, it attempts to run DOS applications with very little virtualization, so I'm not really sure what your code would do on Win9x. However, Win9x has also been end of life for something like 9 years, now, so I'm going to say it's irrelevant.
Derrick Renaud:
--- Quote from: MonMotha on September 24, 2010, 01:03:13 pm ---So, I built this using Visual Studio 2005 as a Win32 console application. inportb is no longer defined by Windows (and hasn't been for a while), so I had to define it myself.
--- End quote ---
I use:
http://www.geekhideout.com/iodll.shtml
That is how I read in the random noise pattern for the SN76477 IC. I clocked and read it through the parallel port.
MonMotha:
--- Quote from: Derrick Renaud on September 24, 2010, 01:18:54 pm ---
--- Quote from: MonMotha on September 24, 2010, 01:03:13 pm ---So, I built this using Visual Studio 2005 as a Win32 console application. inportb is no longer defined by Windows (and hasn't been for a while), so I had to define it myself.
--- End quote ---
I use:
http://www.geekhideout.com/iodll.shtml
That is how I read in the random noise pattern for the SN76477 IC. I clocked and read it through the parallel port.
--- End quote ---
My common solution for direct parallel port access is a little program called "userport" and those routines above, but there are probably better methods, now. I researched that method nearly 7-8 years ago when XP was fairly new, and I was still running Win2k. At minimum, there are solutions that don't require opening up port ranges to every application, now.