From:	Christoph Kukulies <kuku AT gilberto DOT physik DOT rwth-aachen DOT de>
Message-Id:	<199703120927.KAA14768@gilberto.physik.rwth-aachen.de>
Subject:	Re: dpmi_int - any caveats (again)
In-Reply-To:	<Pine.SUN.3.91.970311234430.2704R-100000@is> from Eli Zaretskii at "Mar 11, 97 11:44:51 pm"
To:	eliz AT is DOT elta DOT co DOT il (Eli Zaretskii)
Date:	Wed, 12 Mar 1997 10:27:44 +0100 (MET)
Cc:	kuku AT gilberto DOT physik DOT RWTH-Aachen DOT DE, djgpp AT delorie DOT com
Reply-To:	Christoph Kukulies <kuku AT gilberto DOT physik DOT rwth-aachen DOT de>
MIME-Version:	1.0

> 
> On Tue, 11 Mar 1997, Christoph Kukulies wrote:
> 
> > Could there be any cach flushing effects when using 
> > farpeek(), farpoke() and dpmi_int?
> > 
> > E.g. that a realmode driver sees a certain memory location
> > to be zero while a different value is passed to protected mode?
> 
> I don't think it's at all possible.  A memory location is either
> cached or not, but it never depends on what mode the processor is in,
> AFAIK.  Maybe you should tell a bit more details about the problem,
> though.

Lengthy app specific problem description follows - uninterested readers
please skip:

I'm still fighting with that company's stepper motor driver which is running
in real mode as a TSR (and consumes a terrible amount of CPU, a 386) and
which is a black box to me - no sources.
That driver is invoked with dpmi_int(0x78,&regs); When I want to get
something back from the driver via a memory address I have to pass
that address in bx/cx as seg/offset (I posted a program example recently)
After return from such a call I do a farpeekl(_dos_ds,__tb); (off memory,
don't have access to my own program at the moment since it's sitting in the
DOS box).

One of these functions is 'steer steppers into zero position against the
bumper switches'. When the switches are sensed, the motion stops
and the steppers are steered a bit outwards so that they leave the
switch inactive again. The switch state which is passed back in the
said memory buffer should be zero then. (This all happens while the program
is in their driver). Now and then it happens though, that a
switch state of 0x07 (every axis - xyz - occupies a bit) is passed back.
In that case their driver doesn't react for further motion commands
anyway.

I talked to them and they said they weren't using any hardware interrupts,
were saving all registers. Though one remark they made was about speed,
that presence of emm386 could slow them down, made me become suspicious.

I've ordered a new version of their driver - sometimes this cures problems
magically.

Since I introduced the correct farpokel parameter passing methods I
didn't have a single crashing of the whole system though. But as described,
still these mysterious error.

Maybe I'll take out emm386 and perhaps - although I have greatest 
trust to Charles Sandmanns dpmi provider - try with a different dpmi driver.


> 

--
Chris Christoph P. U. Kukulies kuku AT gil DOT physik DOT rwth-aachen DOT de

- Raw text -