#INP/OUT
12 messages in this thread
Bill, Since you wrote the INPOUT DLL, I figure you must have a lot of
insight into the handling of these routines.
I need a 1 msec (+/- 20%) timed loop independent of platform. In QBX Basic
with INP/OUT the following works perfectly on any machine using a timer
chip (1.193180 x 10^6 precison ticks per second).
SUB dly1000
x% = INP(&H61)
x% = (x% AND &HFC) OR &H1
OUT &H61, x% 'enable gate disable speaker
OUT &H43, &HB0 'set mode
OUT &H42, &H89 'set lo byte(1193 precision)
OUT &H42, &H4 'set hi byte(ticks in 1 msec)
WHILE ((INP(&H61) AND 32) = 0)
WEND END SUB
The problem is using the INP/OUT routines for VB. Supposedly, in the VB
environment, once a Sub is called it runs UNINTERRUPTED by any Windows or
VB background routines. Therefore this same routine should work equally
well in VB as in QBX, IT DOESN"T! In VB the time delay from my routine is
variable from machine to machine varying 300-400%!! IN QBX environment it
runs perfectly on a XT up to a fast 386 (+/- 10-20%).
How are Basic's or C's internal INP/OUT functions compiled so differently
than those in a VB DLL or VBX? The only thing I can see is that the call
to a DLL has a much bigger 'time' overhead. Are routines like INPOUT in a
DLL handled like an overlay? Is there anyway around my problem? Your help
would be greatly appreciated. Thanks.
There are 3 Replies.
Jerry:
Alas, I'm afraid I cannot help you on this…you'll have to ask the VB
gurus on this one. It is my understanding that DLL routines do result in a
performance hit which, in supercritical time routines, may prove
unacceptable. This could tie in to your problem.
Good luck! And let me know whatever you may ultimately discover.
Bill
There is 1 Reply.
Thanks Bill, I'm not saavy enough about how DLL's, VB and Windows tie into
each other. Do you think the problem I described is inherent to programming
a Windows App with VB? vs programming a WinApp with 'C' or is it just
the Windows environment? Can you suggest any 'Guru's' for me to have a
dialog with? Thanks again. <jerry>
There is 1 Reply.
Jerry,
The is fairly substantial overhead when calling DLLs because even
after the procedure address is found, it is still a far rather than a neoffar
call and sometimes involves Windows swapping out the code in the DLL
. The
two recommendations I would make would be to make a DLL which could not be
swapped and to put more of your processing in the DLL. In other words,
create a higher level function than INP/OUT which makes multiple calls to
those function internally.
Another issue that is simply a limitation of Windows has to do with
non-preemptive multi-tasking. The ramification is that the only two ways
to multi-task, DoEvents (PeekMessage) and Timers (WM_TIMER) are based on
empty message queues in other applications which will *never* be fixed
amount of time. Another alternative would be to put a "true" Int 8 handler
in a DLL that would have the ability to multi-task preemptively. Hope this
helps a little. -=- Jonathan
There is 1 Reply.
Jonathan, I felt this coming. After much dialog with others, you
summarized the problems quite succinctly. I'm going to try to write a
non-swapping higher level DLL with QuickC for Windows (I Hope<g>). I keep
you posted. Thanks for the interest.
Jerry
There is 1 Reply.
Jerry,
Good luck. Keep me posted and let me know if there is anything I
can do to help. -=- Jonathan
Hi Jerry,
<I need a 1 msec (+/- 20%) timed loop independent of platform>
I assume you've tried a Timer control because that would be so easy to
test. How much stuff needs to be done between timing loops, or how often
must it be called. I think the Timer control is only good down to 1ms and
adding a DoEvents to allow other processes to run might screw you up. I'll
see if anything comes up when I try it.
–Gregg
There is 1 Reply.
Thanks Gregg, you're right that the smallest TIMER interval is 1 msec but
repetitive calls to TIMER have variable intervals. I need to run a
sequence of timed com port handshaking, ie turn on RTS for a msec, turn it
off for a msec, turn it on again, etc. The device on the other end of my
serial comm port is weird. It doesn't use pins 2,3 for Rx/Tx instead it
recognizes precise on/off sequences of RTS and DSR in a binary-like
fashion. I guess it's coming down to building some dedicated hardware
interface that would convert *normal* RS232 signals into the device
dependent RTS/DSR sequences AND have the hardware interface do the precise
timing loops for sending these sequences to my device. It just seems like
if I can do it in Quickbasic without ANY problems then there should be a
way of doing it in a Windows App. I'm still not sure if the problem rests
with VB or if its some intrinsic problem Windows.
Jerry:
There's an article called "Acurately Timing Windows Events Without Timer
Reprogramming" in the July 1991 Microsoft Systems Journal which describes
"a low-overhead method ot timing events that is accuarte to 1 milliseconds on
all PCs and 100 microseconds on some of the faster ones". I can't pretend
to actually UNDERSTAND the article, but thought it might help you! <g>
There is 1 Reply.
Keith, You make it sound a little frightening <g> but I think I should try
to decipher it. Where can I get a copy of this journal or article? Thanks.
Jerry
There are 2 Replies.
Jerry:
I don't know where you could get this, since MSJ is rare on the newstands.
The Computer Library of your local University might have it. Give me your
address and I'll send you a copy of the article.
Jerry:
I don't know where you could get this, since MSJ is rare on the newstands.
The Computer Library of your local University might have it. Give me your
address and I'll send you a copy of the article.