Announcement

**Eric Pearson** · 10 Aug 2001, 02:08 PM

Is your PB/DOS program running on a DOS computer, or on a Windows computer?

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

**Robert E. Carneal** · 10 Aug 2001, 04:19 PM

PowerBasic for Dos, 3.5. Sorry to that leave out.

**Eric Pearson** · 10 Aug 2001, 06:14 PM

You didn't really leave it out, because you posted your message in the PB/DOS forum.

I was asking whether or not your program was being run on a Windows computer or a DOS computer. It is very difficult to perform accurate "delay" operations on a Windows machine, regardless of the language, because of the way Windows works.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

**Robert E. Carneal** · 10 Aug 2001, 07:21 PM

Got you. Ok, I am running a Windows Me, but running Powerbasic
Dos mode. We will get there yet! This problem is driving me
nuts, I am 99 percent sure there is a way to do it.

------------------

**Paul Dixon** · 11 Aug 2001, 02:46 AM

robert,
look here: http://www.powerbasic.com/support/pb...ad.php?t=22773

paul.

**Eric Pearson** · 11 Aug 2001, 04:27 AM

Robert --

> Powerbasic Dos mode

If you mean that you have rebooted the computer in the DOS mode, you should be ok. If you mean that you are running your PowerBASIC program in a "DOS box", probably not.

Here's the problem...

Windows performs multi-tasking by giving programs "time slices". First one program runs for around 1/100 of a second, then another, and so on. When every program has had its chance, the first program gets another time slice. Even under the best of circumstances this can make it impossible for a program to perform millisecond-accurate timing operations.

If another program "hogs" the processor -- and this is especially true on Windows 95/98/ME -- your program can be prevented from getting any processor time at all for several seconds or minutes.

Additionally, waiting for something to happen can be very tricky. For example...

Code:

DO
    IF SomethingHappens THEN
        ProcessIt
        EXIT LOOP
    END IF
 
    IF TimeOut(1) THEN
        ProcessError
        EXIT LOOP
    END IF
LOOP

Imagine that you want to wait up to 1 second for some kind of event. The loop checks for SomethingHappens after .01 second and it is not True. Then, in the "space" between the two if-tests, Windows gives the processor to another application, and your app doesn't get it back for 5 seconds. When your program gets the CPU the TimeOut(1) has expired and the loop exits, even though the "something" may well have happened within the one second timeout.

It's possible to perform accurate timing on a Windows system, but you must use a Windows programming language. DOS programs can't control Windows like that.

-- Eric

------------------
Perfect Sync Development Tools
Perfect Sync Web Site
Contact Us: mailto:[email protected][email protected]</A>

[This message has been edited by Eric Pearson (edited August 11, 2001).]

**Robert E. Carneal** · 11 Aug 2001, 06:53 AM

Thank you everyone. -Robert

------------------

**Emil Menzel** · 11 Aug 2001, 07:38 AM

Robert:
Be sure that you test out & calibrate any timer routine you
get -- including those you might get from this forum. I
tested more than a dozen myself before settling on this
one (for short delays) & ALL have "side effects" or quirks
of some sort, especially if you run under Windows, as Eric says.

Emil

'WaitaTinyBit -- by E.W. Menzel, Jr. for PB 3.5
'pseudo-clock for short pauses
'accurate to < 1 millisec in DOS; less accurate in Windows
'NOTE THAT THIS SUB MUST CALIBRATE on first call
SUB WaitaTinyBit(seconds AS DOUBLE) STATIC
DIM LoopsPerSec as double
DIM finish as double, X as double
DIM counter as long, N as long

'If we haven't yet calibrated clock, then do it
IF LoopsPerSec = 0 then
counter=1& ' make it >0 to fool calib. loop below
N=5& 'in DOS N=1 might do, but Windows is more variable
X=.05492549#*N 'must not be any MORE than N clock tics
finish=TIMER +.01#
WHILE TIMER < finish: WEND 'wait til next tic
finish=TIMER + X

WHILE TIMER < finish and counter > 0
incr counter
WEND
LoopsPerSec=(1193180#/65536#)* (counter/N)
'''LoopsPerSec=LoopsPerSec/.9519365# 'fudge factor
'''? "Loops Per Millisec";INT(LoopsPerSec/1000)
END IF

finish = TIMER + seconds 'or make it 86401, a dummy value
counter= -(LoopsPerSec * seconds)
WHILE TIMER < finish and counter < 0
incr counter
WEND
END SUB

------------------

**Mike Luther** · 11 Aug 2001, 10:18 AM

You bet Eric..

if another program "hogs" the processor -- and this is especially
true on Windows 95/98/ME -- your program can be prevented from
getting any processor time at all for several seconds or minutes.

This is terribly important where anything depends on the ability
to keep that data coming in and you can't control the sending
source. A prime example is in satellite down-link connections!
The bird is going to send you data .. period.

It is *EXACTLY* why every DOS application now, including all the
tools we use, *MUST* be able to give up time slicing to other
tasks that may be needing them!

It is also, per my feeble understanding of all this, precisely why
the entire WIN operations game is disasterous for the big time
heavy mission telecommunications applications which are SMP
box targets. I'm perfectly willing to be educated here, in fact
I want to be told I'm wrong, if I am, please, please!

The entire WIN game has no capacity to orchestrate CPU assignment
for task switching on the basis of THREAD needs. It can only
assign a CPU to a PROCESS need level.

Thus if you expand this question into precision timing for an
application into the future, and project it onto a box which we
WILL see in common use, sooner than later, solving this problem
in some sort of a standardized way for us in the PowerBASIC user
set is terribly important, I think.

In less time than I think most of us realize, we will be confronted
with task switching requirements for THREAD coordination, even
at the home desktop level, per processor. Yes, that's a bold
statement. But I think it's true.

I know it is hard to realize in many places outside the United States,
but, for all practical purposes, unlimited bandwidth is coming to
many of us sooner than we might think. Glass down to home sites is
far closer to installation in the USA than most folks imagine. I
think the statement I heard a couple years back, which I dismissed
as, "Oh well", is suddenly, introspective! One fiber strand will
carry the entire content of the Library of Congress in about five minutes,
if you ask for it, and they can deliver it!

One second on fiber will carry more than the internet carried in total
data on a month a few years back ... to each and every home!

There is no way, as I distinctly recall the President of Western
Digital tell the Houston Area PC User group less than two years
ago, for storage devices to keep up with processor horsepower
and multi-tasking in the even near-term foreseeable future. He
noted that the average box delivered to the average customer,
by the end of 2001, would be delivered with a 39 MB hard disk,
and that most decent boxes would have two of them.

This was said two years ago near Christmas time in Houston.

A member of the audience (not Mikey!) hollered out, "What for?"

He shot back without even a ripple in his voice, "You'll need
it and it will all be full!"

Processor and task orientation is, as he noted, always two to
three years behind the hardware for storage. He forecast that
this would continue or get worse for long into the future after
the 2001 date he spoke towards.

Thus the only way to work, with what is actually coming in the
way of glass embeddment in home use, is to solve the microsecond
time slice and task re-alignment game ..

now.

It is in my feeble way of looking at it one VERY good reason that
we can't afford to look at all the eggs through the Windows. As
PowerBASIC takes the leap toward UNIX and so on .. hopefully, our
toolset and those around it will somewhat standardize on what must
be done for all to use even older apps, in harmony..

sliced.

We simply won't be able to store it all just to look at it and use
it .. in my opinion.

Hej! I just discovered that OS/2's Spell Checker keyboard shim works
while I'm writing this stuff into the reply window! Gee, maybe
my spelling will improve in this thing where it will trap some
of the misteaks (caught it!) that I always make!!

------------------
Mike Luther
[email protected]

**Don Ward** · 25 Aug 2001, 01:55 AM

I use the following code to wait one millisecond for my morse
tutor programs, it seems to work OK on most Windows versions for
my DOS programs but I would welcome comments from those more
knowledgable than I! It uses the hardware timer.

Code:

sub onems
 ! pushf         ; save flags
 ! cli           ; stop interrupts
 ! xor al,al     ; set al=0
 ! out &h43,al   ; latch timer 0
 ! xor al,al     ; delay
 ! in al,&h40    ; input lo byte of counter
 ! mov dl,al
 ! in al,&h40    ; input hi byte of counter
 ! popf          ; enable interrupts
 ! mov dh,al     ; count now in dx
 
w1ms:
 ! pushf         ; save flags
 ! cli           ; stop interrupts
 ! xor al,al     ; set al=0
 ! out &h43,al   ; latch timer 0
 ! xor al,al     ; delay
 ! in al,&h40    ; input lo byte of counter
 ! mov ah,al
 ! in al,&h40    ; input hi byte of counter
 ! popf          ; enable interrupts
 ! xchg ah,al    ; count now in ax
 ! mov bx,dx     ; copy intial count
 ! sub bx,ax
 ! cmp bx,&h938  ; 1 millisec
 ! jl w1ms
end sub

You can build this into a function or sub to select the delay.

Cheers,

Don Ward

------------------

**Mike Luther** · 25 Aug 2001, 07:10 AM

Oh Thank you Don! Bless you!

What a perfect example to use for a demonstration of the absolute
destruction of CPU performance by the PB IDE that you can't break
into giving you time slice releases! Add a little BASIC test snip
to Dan's suggested code as in:

Code:

CLS
PRINT TIME$
FOR NJ% = 1 TO 2000
   ' IF NJ% = 990 THEN PRINT " -> "; TIME$
   CALL onems
NEXT NJ%
PRINT TIME$

The couple of PRINT statements may keep the results from rolling
off the screen if you run it in an compiled executable, that's all.

You may find that in a DOS-VDM session in OS/2 that you have to
set the HW_TIMER=ON in the session setting commands. In OS/2 we
have the option to let any specific session have access to the
hardware ports, on an optional basis, in stark contrast to what
is offered in the WIN arena, as I am told. At any rate, one way
or the other you will get the following output on your screen:

13:27:12
13:27:14

Interestingly, it also opens a path to proving up system capability
to, at least from a per second basis, to resolve TIMER issues, even
perhaps to the millisecond, in your operating system, even though an
integer loop is making 2000 CALLS to that routine. Let's not get
into the game of how many milliseconds this may be off in precision
loops for gating EG&G trigger switches used for the detonation of
nuclear devices, please! (I have used them for peaceful purposes!)
Uncomment the step print comment above and exxpand on it if you want
to play and think about how to prove a millisecond might or might
not be critical from one second to the next.. whatever.

I got the above, for example, with 18 active tasks, 36 processes,
and 152 threads running simultaneously on the box on which this
demo was run. It's a good demonstration of the real capabilities
of OS/2, as well as both PowerBASIC's absolute superiority in speed
as well as it's brilliance in the use of inline assembler!

Now, watch the total destruction of the system from the use of the
PB IDE as to timing.

Load TWO instances of the PB product in SEPARATE DOS-VDM sessions in
OS/2. Bring up the IDE in both! That gives you two loads of the IDE
just for demo purposes. In ONE of them just execute the little snip
above for you mystical trip into two second timer land, whilst the
other one is still sitting in the IDE waiting your command. Voila!

13:43:38
13:44:21

Total destruction of all timing relationships for EVERYTHING, including
even native OS/2 applications!

It's not possible in this forum to demonstrate the exact destruction in
native OS/2 applications that are important to me. I don't have the
source to provide the step output to do that for them, but the malady
*CAN* be shown with nothing other than the above which is only a very
few lines of code.

Now, PLEASE, PLEASE, PLEASE .. may we have some help to be able to
break up the polling problem in the PB IDE and DEBUGGER. You simply
can't afford to go off and leave the IDE or DEBUGGER up on any time
sensitive box. Even a suggestion as to a utility that will break it
up, while still leaving control for other applications that do respond
to the tools I know about, will be fine.

Thanks ..

------------------
Mike Luther
[email protected]

**Lance Edmonds** · 25 Aug 2001, 07:35 AM

In the Windows world, you can coarsely adjust the amount of CPU time that is allocated to a DOS application through the Properties box. However, since the quantum is usually 10mSec or more, reliable 1mS timing in Windows is difficult to guarantee. Using a critical section interrupt can help, but not recommended for long durations.

Basically, if you need tight millisecond timing, running a multi-tasking O/S is not recommended.

In any case, Mike, doesn't OS/2 allow you to set the Idle-detect and/or time slices for DOS applications in the same way? (Even Windows 3.x provided this ability)

If not, why not?

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

**Mike Luther** · 25 Aug 2001, 08:20 AM

As a matter of fact, Lance ..

In any case, Mike, doesn't OS/2 allow you to set the Idle-detect
and/or time slices for DOS applications in the same way?
(Even Windows 3.x provided this ability)

It DOES! It's not well known, but there are two lines you can add in
your CONFIG.SYS for OS/2 that, as I understand it, changes the
entire PRE-EMPTIVE multi-tasking for OS/2 to what it was/is like
in WIN and, particularly, in Desqview. For those interested, the
command line you may add in your OS/2 CONFIG.SYS file are:

Code:

REM ** Is the standard PRIORITY=DYNAMIC
PRIORITY=ABSOLUTE
TIMESLICE=256,320

OS/2 is a PRE-EMPTIVE multi-tasker and a fantastic one at that! One
of the major reasons that it failed to gain the huge following in
the single user market place it that it's very difficult to play
games on it that were DOS or WIN oriented. Arguably, everthing's an
argument, DOS in OS/2 is a better DOS, a far better DOS, than DOS! And
with that comes the flip side that, for timing purposes, DOS and,
Windows needed/s a much different operating set of thinking for
applications in multi-tasking than it had/has .. in certain of its
versions. This is *NOT* a comment in respect to WIN-NT, nor some
of the later versions of the user enablement of the NT-style code at
all which have come much, much later down this pig trail.

Part of the reasons why PoweerBASIC applications fail miserably in
telecommunications applications when loaded for more than just a few
of them at any given time in WIN-95 and WIN-98 boxes is related to
just how poorly the WIN operations handle all this for them.

Those limitations simply do not exist in OS/2 DOS emulations, and, yes,
DOS is nothing more than an emulation, an OBJECT, if you please, while
in the OS/2 arema.

In the case of the use of the above switches in your CONFIG.SYS line,
what you are doing is to change OS/2 from its very well thought out
PRE-EMPTIVE format, again, to a fixed time slice format. The second
line in the suggested change to CONFIG.SYS provides for a specific
number of task switches, in milliseconds, that the CPU is expected
to give to the foreground and the background, respectively. Early on
as all this multi-tasking developed in respect to desktop units as
CPU's began to gain horsepwer and re-entrancy was defined for the
better operating systems to make use of them, those of us in the DOS
BBS world worried and experimented at length with this!

We came to the very valid conclusion that OS/2 could do a far better
job of deciding on what was a valid pre-emtive need for the various
applications running under the operating system than we, or Desqview,
or any WIN application could do. That wealth of experience which IBM
had/has in relation to mainframe operations shows over and over again
in all this, for many years. It took Microsoft many, many years to
even come close to this, in my opinion, until at least WIN-NT3.

The actual crucial reason that this is still far more important than
most folks believe and why it MUST be solved for those of us who
write applications which are DOS based is this! More and more we
will be using them on the mulit-tasking systems. That is going to
happen; period. In fact, a pure DOS based suite of many many programs
can do a perfectly fantastic job in OS/2, written in entirely the 3.5
PowerBASIC product. You can run a dozen applications in separate
sessions on an embedded box, including telecommunications applications
at the same time. To the extent that you solve the inter-related file
and comm I/O problems with semaphore technques, who cares?

In fact, a semaphore at the file I/O level, is much the same thing,
as a semaphore at code level, wherein the actual code can create
THREADS too. It is in this THREAD level code that we see the rest
of the meed for DOS applications to be able to leave the operating
system a chance for task switching!

You see, OS/2 and UNIX also, so I am told. have the ability to do full
Symetric Multi-tasking of the CPU on a PER-THREAD basis! As far as I
have been able to learn from lurking, but do not know from experience,
that is precisely the reason that the entire WIN operations are closed
to the really huge transaction processing game. They can only be used
for SMP at the PROCESS per CPU level! In other words, in the arena
of the SMP game, a PowerBASIC application written for DOS, will take ]
a single CPU to run it, irrespective of how many people, on a thread
basis, might be assigned to that same task!

That same sort of logic, is the reason, we were told, in the data that
was released in the OS/2 groups, that even Microsoft was forced to
abandone their entire world-wide barrage of some 1700 WIN-NT servers
amd go right back to the same twenty-three (23) AIX-400's that had
been handling the entire world-wide operations for them! The issue of
THREAD based CPU and task alignment, even when carried down to the
individual DOS level program, is terribly critical as these CPU's,
boxes, and operating systems get better and better.

Please do NOT shoot the messanger. I don't pose to be any sort of
expert at all at this. You asked:

If not, why not?

As a very lowely peon at all this, I have done my best to tell you
exactly why not, as I understand all this at my level of awareness.

Please .. may we have some help for the IDE and DEBUGGER at this?

------------------
Mike Luther
[email protected]

**Dave Stanton** · 26 Aug 2001, 06:21 PM

robert,
if you are operating in 'real' dos the following snippet my be of use:

Code:

     sub delaymsec(byval msc??) public
         local usec???
         usec???=msc??
         shift left usec???,10
         ! push ds
         ! mov ax,&h8600
         ! mov cx,usec???[02]
         ! mov dx,usec???[00]
         ! int &h15
         ! pop ds
     end sub

if in windows then the code i posted works well with the noted provisos:
http://www.powerbasic.com/support/pb...ead.php?t=3701

dave

------------------

**Don Ward** · 7 Sep 2001, 10:21 AM

That's a very interesting millisecond delay Dave. My DOS bible
doesn't list that function for INT &H15. I have tried it and
it works for me but it does n+1 milliseconds so a 1 millisecond
delay needs a call with zero. Where can I find this function
listed?
Don

------------------

**Dave Stanton** · 7 Sep 2001, 07:07 PM

Don,
I have it listed in a number of books, including:

PC Intern by Michael Tischer ABACUS 1992

The undocumented PC by Frank van Gilluwe Addison-Wesley 1994
ISBN 0-201-62277-7

I've never experienced the n+1 problem, except to say that
the first time it's called there sometimes is a slight delay,
varies from computer to computer, after that it's pretty good.
I always do a dummy call somewhere at the start of the program
where it's not important.

Dave

------------------

**Don Ward** · 8 Sep 2001, 05:51 AM

I put it in a 1000 loop called with zero (I cheated and set cx,dx
to zero) and printed a count versus time$. It went slightly faster
than time$.
Don

------------------

**Robert E. Carneal** · 8 Sep 2001, 06:13 AM

<Quote from Dave>
PC Intern by Michael Tischer ABACUS 1992

The undocumented PC by Frank van Gilluwe Addison-Wesley 1994
ISBN 0-201-62277-7
<End quote from Dave>

Dave, please verify that ISBN number for me. The local bookstore
drew a blank with that number. If it is accurate, I will just go
to another bookstore or get it off an online bookstore.

Thank you.

Robert

------------------

**Lance Edmonds** · 8 Sep 2001, 06:45 AM

When normal bookshops fail, try http://www.alibris.com

http://www.alibris.com/search/detail...tches=1&qsort=

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

Announcement

Small increments of time?

Small increments of time?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment