Mail Archives: djgpp/1998/01/06/14:31:47
Jeff Weeks writes:
>I have a fair bit of mouse programming docs around here and I seem to
>remember that the mouse can be accessed from port 3F8.
If it is a serial mouse, yes. But there are many other types of mice
that won't work if you bypass the standard driver in this way, and your
program will probably also cause problems with things like win95 that
emulate the int 0x33 driver but may not support raw serial access...
>If so, can I read from ports without switching to real mode
Yes. Port accesses are significantly slower in protected mode than in
real mode, because of the need to check the I/O permission tables, but
nothing like as bad as a mode switch. If things are really critical you
can avoid this by running in ring 0 (use cwsdpr0) but the difference is
usually negligible and I wouldn't be at all concerned about this for
something like a mouse handler.
You should be aware that in some situations (when running under a more
advanced OS than plain MSDOS) a port access can generate an interrupt,
however. For example under win95 your program will never be able to
directly access the soundcard, timer, and other such chips: any
references to these ports causes an exception which is trapped by the
win95 drivers, and they then emulate whatever you were trying to do
(sometimes very badly :-) This is how they are able to run multiple
programs at the same time, even when the programs assume that they have
complete control over all the hardware...
>My guess is that I can just have this function read from the above port
>and return what information it finds. I don't even need to mess around
>in interrupts do I?
I don't think it works like that: my understanding (based on when I used
to read the mouse this way in very early versions of Allegro, before I
ditched that code in favour of int 0x33) is that you will get an
interrupt every time the mouse moves and only then can you read the
button state and movement deltas from the serial port. And the only
thing you get from the hardware is a motion count, so you will have to
convert that to a position (I found some sort of logarithmic response
was needed to get a nice smooth movement: some tweaking may be
required).
But really, I think it would be crazy to write such code. I can't see
any reason not to use the standard DOS driver, which is widely
documented and can do everything you need (either polling for the
position or generating callbacks when the mouse moves). The only thing
it won't do for you is to display a pointer in SVGA modes, but you'd
have to write that code for your own handler in any case so there is no
loss in letting the OS talk to the hardware for you...
--
Shawn Hargreaves - shawn AT talula DOT demon DOT co DOT uk - http://www.talula.demon.co.uk/
"Pigs use it for a tambourine" - Frank Zappa
- Raw text -