Date: Wed, 12 Mar 1997 15:57:25 +0200 (IST) From: Eli Zaretskii To: Christoph Kukulies cc: kuku AT gilberto DOT physik DOT RWTH-Aachen DOT DE, djgpp AT delorie DOT com Subject: Re: dpmi_int - any caveats (again) In-Reply-To: <199703120927.KAA14768@gilberto.physik.rwth-aachen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 12 Mar 1997, Christoph Kukulies wrote: > 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. If I understand correctly, the real-mode driver writes the switch state into the buffer whose address you pass it (in your case, the DJGPP transfer buffer), right? If so, then this doesn't seem like a cache-related issue at all: once that address is written, it is marked dirty in the cache and either written to memory right away, or (if your cache has write-back operation enabled) will cause the CPU to supply the data from the cache to any other access to that address. However, there's one caveat that you should be aware of when using the transfer buffer. If you call any library functions between the moment the driver puts the switch state into __tb and the moment you read the state with `_farpeekl', you should make sure that those library functions don't themselves use the transfer buffer. If they do, they will overwrite its contents. For example, if you use file I/O functions or `printf' before fetching the data from __tb, you will see such problems. Other than that, I'd indeed suspect EMM or some other oddity with the driver.