Announcement

**Mel Bishop** · 6 Jul 2000, 07:13 PM

The LineInput function works but if you need to use INKEY$, try
using the following example:

Row = 12
Col = 30
locate row,col
color 22,1 'Set to blinking
print;chr$(95); 'Underscore character
color 6,1 'Back to normal color mode
locate row,col

do
if inkey$ = {something} then exit loop
loop

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

**Jerry Fielden** · 6 Jul 2000, 07:13 PM

Fred

Here's another Example, maybe you can use.

[CODE]
DECLARE SUB GetKey(Keynumber%, char$)

Enter = 13
SpaceBar = 32
Escape = 27
BackSpace = 8
RightArrow = 19712
LeftArrow = 19200
Downarrow = 20480
UpArrow = 18432
Row% = 1
Column% = 1
Locate Row%,Column%,5
cls

DO
GetKey Keynumber%, char$

Select Case Keynumber%

CASE Escape
EXIT DO

CASE SpaceBar
INCR Column%
Locate Row%, Column%
PRINT CHR$(32);

CASE Enter
Column% = 1
INCR Row%

CASE BackSpace
DECR Column%
Locate Row%, Column%
PRINT CHR$(32);

CASE LeftArrow
DECR Column%

CASE RightArrow
INCR Column%

CASE DownArrow
INCR Row%

CASE UpArrow
DECR Row%

CASE ELSE
PRINT Char$;
INCR Column%

END SELECT

IF Column% > 80 Then INCR Row% : Column% = 1
IF Row% > 25 then Beep : row% = 25
Locate Row%, Column%

LOOP

SUB GetKey(Keynumber%, char$)
char$ = "": Keynumber% = 0
DO
char$ = INKEY$
IF char$ <> "" THEN EXIT DO
LOOP
Keynumber% = CVI(char$ + CHR$(0))
END SUB

[CODE\]

If you want to see the Keynumbers% that each Key generates
put PRINT Keynumber% somewhere in your code.

This is one example, I'm sure there is more and better ones
out there somewhere. ABC has a bunch of Basic Code snippets
that might include some more examples. Their address is http://www.basicguru.com/abc/
If you search, you might find a few here.

I hope this helps.......Jerry

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

[This message has been edited by Jerry Fielden (edited July 06, 2000).]

**Mike Luther** · 6 Jul 2000, 08:22 PM

There is one thing that may be useful to all of you in this discussion
that you may want to think about in making up loops with INKEY$.

INKEY$, as well as the SLEEP function, by themselves, are terrible
problems in multi-tasking environments, as provided by PB-DOS 3.5.
At least my experience with them is. What they are doing is to
constantly go around again and again asking, "is there anything
waiting at the keyboard for me now?" If the DOS PB-3.5 program is
being written for only pure DOS and that is the only application
that is to be run on the CPU at one time, this is fine.

Nowdays, however, more and more you will find programs which may be
in DOS, but are winding up being run on WIN-95, WIN-98, WIN-NT in
a DOS-EMU for LINUX and OS/2. Those programs, with the pure INKEY$
loops that are developing and being suggested here .. will tear a
CPU operation all to Hades polling them, demanding attention, while
the CPU really needs to be shared with perhaps many different
processes. For example, as I write this, there are two PB 3.5 DOS
applications running constantly looking for input on my OS/2 box
in separate DOS-VDM sessions. However, they don't *NORMALLY* do that
with INKEY$ .. they are muzzled.

First, maybe you don't think this is too important. What can one
or two applications cost at a time. It isn't that simple. As I
write this there are currently ... ONE HUNDRED SEVENTY ONE (171!)
actually threads running on this computer and CPU in SEVENTEEN (17)
actual separate applications on this CPU as I write this!

More important, including the *TWO* PB 3.5 apps running, the total
processor CPU load on the whole 350Mhz unit is less than 3% of its
total available load level! Thank you OS/2, but that's only part
of the story. The rest is terribly important here.

First, there are commercially available and shareware and even some
freeware utilities whose function is to break up polling applications
like this INKEY$ loop deal stuff. They force the program, no matter
how, normally, it is written, to give up time slices to the CPU so
that other things can be effectively done in modern systems. That
is true even though the basic program may have been written with,
say keyboard, or COM port, timer polling, whatever. MOST of the time
they can help. Examples of the are TAME320, OSTSR, which are commonly
used to help..

On the other hand there are programs that are so well written to smash
the CPU, that no possible combination of time-slice relief utility
that I can find can quiet them. PB 3.5 in the IDE development mode
happens to be one of these that I can find absolutely *NO* way to
keep it from totally trashing the CPU when it is in the IDE mode
part itself!

On the other end of the scale, for INKEY$ and SLEEP and ON TIMER
and so on, it becomes necessary to employ some trickery to keep them
from trashing the system as well.

As a general suggestion, the only way that I have found that one can
keep INKEY$ from trashing the CPU, is to embed a small Assembly
in-line routine in the INKEY$ loop. Remember, we are looking for
letter-text rate keyboard I/O here, folks, not joystick response
for games and so on. This is a simple text I/O routine as such.

The way that I have found that one can break this up in WIN-98 an
OS/2 sessions that use PB 3.5 keyboard I/O is to simply use the
following addition to the "loop":

Code:

         REG %AX, &H8600 '                      Function $AH68in AH
         REG %CX, &H00 '                        Less than 1000 MS delay
         REG %DX, &HFF00 '                      Try this for a delay
         CALL INTERRUPT &H15 '                  Call Interrupt 15H timer

         Z0$ = INKEY$ '                         Now look at keyboard!

It may be all wrong to do this somehow and someone else has a better way
to get this done. However in over ten years of this game, this
simple ASR added to the entry to the INKEY$ line, has never failed
us at keeping the CPU totally quiet in any WIN-95/8 or OS/2 DOS-VDM
session. As far as I can tell, there has never been a typist that is
routinely using the keyboard I/O that has ever complained that
the keyboard is too slow or unresponsive!

That same trick can be worked into the SLEEP routine, and also,
with care, added to the ON TIMER deal as well. I've had as many
as sixteen, I think, separate PB 3.5 applications running at the
same time in DOS-VDM sessions in OS/2 and the processor, if looking
for just keyboard I/O will never even show a ripple off the 0%
level on the WPS (Toolbar to you WIN-9x crew!) pulse graph that
rides for all us OS/2 users constantly!

I invite you folks to add this little in-line ASR code to these
routines and see if it really makes any difference in the user
interface to them! I think you will find there is none. If it
falls to anyone to use your code in the multi-tasking game, my
thought is that your users will be *SO* glad you were thoughtful
of them and put an end to keyboard polling for them in advance!

If only the PB crew would give us some similar relief on the PB IDE
itself, it would be greatly appreciated by those of us that do
intensive work with the IDE or the PBD which has the same fault.
Although less and less of us are still using the old classic Intel
CPU with the semaphore bug flaw, there are plenty of then out there.
In that case, this INKEY$ polling deal and also the PB IDE and PBD,
if left running constantly in that maxed CPU mode, can actually
cause disk I/O and system data loss from the F0 bug flaw that they
can precipitate by keeping the processor maxed out in load mode.
It's happened to me more than once when I didn't know what was at
the bottom of this and went off leaving test systems up and smasho
on the CPU meter!

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

**Tom Hanlin** · 7 Jul 2000, 08:53 AM

The IDE doesn't seem to take up excessive time under Windows 2000, but I haven't checked other OSes. Also, the INT 15h timer is not available on all machines. However, it is interesting to hear about the problem and proposed solution, and we will consider it for the next PB/DOS revision.

------------------
Tom Hanlin
PowerBASIC Staff

**Jerry Fielden** · 7 Jul 2000, 08:25 PM

Mike

Do you think

WHILE NOT INSTAT: WEND: Char$ = INKEY$

would cause the same problem with multitasking while in a Loop.
I noticed that you had left it out of possible causes. It looks
like it could cause the same problem. But I'm no expert in these
matters.

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

**Mike Luther** · 7 Jul 2000, 09:26 PM

Jerry!

You know .. I just tried it! It doesn't smash an OS/2 DOS-VDM
session with OSTSR loadhigh c:\u\ostsr 3, together with the
TAME program loaded as loadhigh tame /TINY /I 9 /TS OS/2..

I thought that it would so I never tried it!

To work .. I coded the following:

Code:

10

    WHILE NOT INSTAT

    WEND

    CHAR$ = INKEY$

    IF CHAR$ = CHR$(13) THEN

       END

    END IF

    PRINT CHAR$;

    GOTO 10

CPU is totally flat at this point. This may be a far better way
to do it as this Tom's point was correct. The ASM won't be a
way to do this in all cases .. If your suggestion does, in fact
work, then at least for KEYBOARD detoxification, it would open
up that to more boxes...

To check this out further, now I've got to reset the SESSION setting
stuff in the test DOS-VDM in OS/2 .. Then I've got to compile this
tiny snip and try it on WIN-9x boxes, as well as find someone that
is using WIN-NT to try it. Someone else can test that here faster
than I can, methinks...

That still doesn't solve the problem of polling smasho for the
SLEEP and TIMER functions ... Any thoughts on what we might do
to get them out of INT land? It would be wonderful to get out of
the ASM snippet for those too ...

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

**Mike Luther** · 7 Jul 2000, 09:46 PM

I can't resist this ..

Tom and Jerry!

I just tried the suggestion by Jerry without any polling protection
in the OS/2 DOS-VDM session game. Bad luck, rats and hamsters ;(

Unfortunately it roars off totally with the CPU unless I load
TAME320 as part of the AUTOEXEC.BAT run for the session. You can
use any sort of ####EXEC.BAT file you want for any DOS-VDM session
in OS/2, just give it whatever batch file name you want. Thus it
is easy to test stuff like this ..

Without TAME loaded, we've off to the moon on a rocket for CPU
polling with Jerry's suggestion ...

Tom .. is there *ANY* substitute that you know about for the INT 15
code that is a better solution? I'd really like to know it if
there is as I know there are limitations with it...

While you folks are mulling it over, as part of the IDE fix we
have badly needed for so long at this, the R&D crew might also
give thought as to how to break up the polling game for INKEY$
and SLEEP and the TIMER game too. It might take a separated
parameter of some kind that you use for these functions to let
the user select the alternate and some form of a controllable
poll damping for them, as desired. If you folks did that, you
would, I think, markedly extend the lifespan of the PB 3.5
product on into the future where we are all going to be forced
to go to more and more multi-tasking as a fact of life..

Thanks ...

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

**Dave Stanton** · 7 Jul 2000, 11:21 PM

This may be of use
Dave

Code:

$IF 0
                          "TRINPUT.BAS"
                           6/2/98
                            by dls
                      Placed in the public domain
                      Transient INPUT replacement

         Trinput returns 0 if a terminated input is still pending
         but returns 1 if an input is terminated by either an [Enter]
         or [Esc].
         If terminated with [Enter] it returns in Answer$ whatever
         was entered, if by [Esc] it returns a null string.
         It is transient in the sense that if there is no keyboard
         activity then you can use the time doing other things.
         The only limitation is the time to fill the normal keyboard
         buffer, a second or two, it will catch up with the input
         when time is available.

$ENDIF
        ' Constants
        %BS=8
        %CR=13
        %ESC=27
        %HOM=256*71
        %LFT=256*75
        %RGT=256*77
        %END=256*79
        %INS=256*82
        %DEL=256*83
        %TRINBUFSIZE=33 'Input buffer size - make it what you want

        CLS
        LOCATE 10,20     'Setup position of input
        DO
          IF Trinput("Please give an answer",Answer$) THEN EXIT LOOP
          Showtime
          Screenthings
        LOOP
        LOCATE 4,20
        IF LEN(Answer$) THEN
           PRINT "You entered "+Answer$
        ELSE
           PRINT "You didn't enter anything"
        END IF
        END


        SUB Showtime
            LOCATE 1,1
            PRINT Time$+" "+Date$;
        END SUB

        SUB Screenthings
            LOCATE 12+13*RND,1+79*RND
            PRINT CHR$(64+16*RND);
        END SUB


        FUNCTION Trinput(BYVAL Question$,Answer$) AS BYTE
            STATIC Status?,Oldrow?,Oldcol?,Buf$,Cursorpos?
            STATIC Lq?,Nextchar?,Instate?
            LOCAL K??

            IF Status?=0 THEN   ' First time in
               Status?=1
               Instate?=0
               Buf$=STRING$(%TRINBUFSIZE,0)
               Nextchar?=INSTR(Buf$,CHR$(0))
               Oldrow?=CSRLIN
               Oldcol?=POS
               Display Oldrow?,Oldcol?,Question$+"? "+LEFT$(Buf$,Nextchar?)
               Lq?=LEN(Question$)+1
               Cursorpos?=1
            END IF

            IF INSTAT THEN
               K??=CVWRD(INKEY$+CHR$(0))
               SELECT CASE K??
               CASE %CR
                 Answer$=LEFT$(Buf$,Nextchar?-1)
                 Status?=0
               CASE %ESC
                 Answer$=""
                 Status?=0
               CASE %BS
                 Cursorpos?=MAX(1,Cursorpos?-1)
                 Buf$=Removechar$(Buf$,Cursorpos?)
               CASE %HOM
                 Cursorpos?=1
               CASE %LFT
                 Cursorpos?=MAX(1,Cursorpos?-1)
               CASE %RGT
                 IF Nextchar?>Cursorpos? THEN INCR Cursorpos?
               CASE %END
                 Cursorpos?=Nextchar?
               CASE %INS
                 Instate?=(Instate?+1) MOD 2
               CASE %DEL
                 Buf$=Removechar$(Buf$,Cursorpos?)
               CASE <256
                 IF Instate? THEN
                    Buf$=LEFT$(Buf$,Cursorpos?-1)+" "+MID$(Buf$,Cursorpos?)
                 END IF
                 ASC(Buf$,Cursorpos?)=K??
                 Cursorpos?=MIN(%TRINBUFSIZE,Cursorpos?+1)
               END SELECT
               Nextchar?=INSTR(Buf$,CHR$(0))
               Display Oldrow?,Oldcol?,Question$+"? "+LEFT$(Buf$,Nextchar?)
            END IF
            Setcursor Oldrow?,Oldcol?+Lq?+Cursorpos?,0,Instate?
            FUNCTION=(Status?+1) MOD 2  ' Invert Status?
        END FUNCTION

        SUB Setcursor(BYVAL Row?,BYVAL Col?,BYVAL Page?,BYVAL Instate?)
            LOCAL Cursize??
            IF Instate? THEN
               Cursize?? = &H0208 'Line 2 to 8
            ELSE
               Cursize?? = &H0708 'Line 7 to 8
            END IF
            DECR Row?            ' Zero base
            DECR Col?            ' Zero base
            !    MOV AX,&H0100   ; Set cursor size
            !    MOV CX,Cursize??
            !    INT &H10
            !    MOV AX,&H0200   ; Setcursor position
            !    MOV BH,Page?    ; Select page
            !    MOV DL,Col?
            !    MOV DH,Row?
            !    INT &H10
        END SUB

        FUNCTION Removechar$(BYVAL Q$,BYVAL Posn?)
            ASC(Q$,Posn?)=255
            FUNCTION=REMOVE$(Q$,CHR$(255))+CHR$(0)
        END FUNCTION

        SUB Display(BYVAL Row?,BYVAL Col?,BYVAL Q$)
            LOCATE Row?,Col?
            PRINT Q$;
        END SUB

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

[This message has been edited by Dave Stanton (edited July 08, 2000).]

**Jerry Fielden** · 8 Jul 2000, 04:05 AM

Mike

Would putting DELAY .05 before INKEY$ while in a LOOP allow
the CPU enough time to Share with other programs, or will it
stop the CPU dead in it's tracks?

DO
DELAY .05
Char$ = INKEY$
IF Char$ <> "" THEN EXIT DO
LOOP

....Jerry

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

[This message has been edited by Jerry Fielden (edited July 08, 2000).]

**Mike Luther** · 8 Jul 2000, 05:47 AM

Jerry ..

I tried you suggestion without any protection from OSTSR or TAME
in a DOS-VDM session in OS/2 ...

BLAM!

Humor here! 'You have just been attacked by a level 9 key troll!'

He has stolen your CPU!

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

**Mike Luther** · 8 Jul 2000, 07:02 AM

Dave

An interesting real beginning of a keyboard I/O routine. It
thoughtfully shows the screen perspective of the whole deal as well
as it also gives one a real chance to see exactly where the CPU
destruction occurs during multi-tasking, even with full pre-emptive
multi-tasking such as OS/2 offers!

For those not having thought about it yet, in theory, pre-emptive
multi-taskers, such as OS/2, are supposed to have the ability to
decide on the basis of relative importance of many processes, which
one(s) should be given more time in the time-slicing game.

If you think about it, the CPU can, in a crude manner of speaking,
do only one thing at a time. Thus, if you wish to do two things at
a time, in a crude way of speaking, with a CPU, what you must do is
generate a list of tasks. You then give instructions to the CPU to
divide its efforts on the basis of some algorithim, so many cycles
to one task, so many cycles to another. What is really happening
when you do this is that the CPU really isn't doing two things at
once, but is spending a moment doing this, a moment doing that, a
moment doing something else. Because it shifts gears and does these
things so quickly, the user perceives that it is doing more than one
thing at a time when, in reality, it isn't.

That's why, as we get more and more things going at psuedo-once, we
need faster and faster CPU's .. gobble-gobble!

DesqView was a time slicer and task controller that was oriented
toward giving a FIXED number of CPU CYCLES to one task, then to
giving a FIXED number of CPU CYCLES to another one. You could lay
out conditions where it may have given 7 to one; 5 to another, and
so on, but the slicing was still rather fixed by the design of the
load matrix for the programs.

OS/2 and WIN-NT are what we call pre-emptive multi-taskers! They
are the 'next generation' of multi-program control templates, which
were originally designed to do a better job of orchestrating CPU
time cycles between a number of processes. In the scheme of things,
we might want to have, for example, a telecommunications program
that is downloading data from a satellite running at the same time
we are simply typing a letter to someone.

In DesqView, the ratio of time that the CPU took for each of those
program could have been set up in a fixed way. We, for example,
knowing that the satellite down-loader needed a lot of attention,
could be set for 90% of the time and the typing program could be
set for only 10% of the time. In truth, if those two programs were
the only programs we ever ran, the system would work just fine, and
as a matter of fact, did work VERY well for well-designed static
program mix systems.

However, suddenly we now decide we want to process a picture that
has arrived via the satellite! So, on the fly, we load up PMVIEW,
for example to see it! Trouble in River City! Our planning as to
the relative importance of timing is all awry.

OS/2 and WIN-NT, LINUX, for example, all are designed to make a
moving dynamic decision on the relative importance of what the CPU
should be doing on the fly! For example, while we may really need
a burst of CPU time for a quick barrage of letters we type in one
creative dash of a sentence in the word processor, we pause to think
of what to write next. In that pause, OS/2, WIN-NT, LINUX, VMS, and
the other full pre-emptive multi-taskers realize that the keyboard
has fallen silent. They, analyze the silence. They make a prediction
that the keyboard will remain silent for longer, and, until it comes
alive again, they adjust the time available for the satellite and the
PMVIEW program to give them more time for action!

Much better!

I chose these three applications for examples, however, for a reason!
While looking at PMVIEW can be delayed for a few thousandths of a
second and you'll never notice it, downloading from the satellite is
another story! It doesn't give a tinker's dink on a pot about the
receiver below if it is in pure broadcast mode! Thus, the whole
CPU receiving program *MUST* be fast enough, no matter what, to pull
in the ongoing barrage of data, and switch away from that task, *ONLY*
when there is idle time in it to do so!

Thus, *ANY* program which is designed to use keyboard I/O, comm port
I/O, timer I/O for any reason, *MUST*, these modern days, have some
way of building in a process where during idle time for that program's
I/O stream, it can RELEASE TIME SLICES for other programs. It simply
is no longer acceptable for any modern compiler to allow creation
of a program that demands total attention to a CPU as a de-facto
standard of its work. That's true of both the program as a utility
itself, as well as the code it creates in pure DOS too.

While we do have utilities that can, most of the time, break up even
many of these errant polling-type programs, even a VERY good pre-emptive
multi-tasker such as OS/2, can become totally reduced to absolute
maximum CPU use by some types of I/O techniques.

Ordinarily, although it's only bad policy to allow any program to do
this, the results of total CPU domination are not fatal. Its just bad
technique to do it. However, in one very important case, there is a
little known, and frankly, seldom seen error in the design of all the
Intel Classic Pentium CPU's up to what I have been told is the 330 Mhz
versions, and it includes all the MMX versions as well.

There is a flaw in the semaphore register section of these chips. The
semaphore register, in a simplistic sense, is part of the traffic cop
operations for the CPU. It's 64 different ranks of task swap can
be, under certain circumstances, host to the decisions as to what
needs more and what needs less time to operate. It's part of the real
true multi-tasking decision making process. In what has been called,
as I understand ... bitterly too, about all this, in *ALL* the old
Classic Pentiums. If, the semaphore register has a roll-over error if
it gets full and hard disk I/O is needed at just the right instant
in time when the 64 segments of that register are full ... and that
I/O is present on the partition from which the program is loaded,

at MAXIMUM CPU LOAD ... BLAM!

At that point, because of the roll-over error, the entire system
can and *DOES* lock up. Any disk I/O that is going on at that
time *MAY* become corrupted. Recall that in a multi-tasker, if
you are writing, for example the file allocation tables of your
hard disk when it happens ..

your hard disk can become toast.

The bug is called the F0 Bug. This discussion is important, even
though long and complex, because any DOS program which can max out
the CPU in a polling manner, can set up PRECISELY the process in
these Classic Pentium CPU's that will and does provoke the disk
trashing problem.

I personally, in development work in DOS-VDM's with Classic Pentimns
using PowerBASIC 3.5, have had to totally rebuild my developement
box on three separate occaisions from tape from leaving the PB IDE or
PBD debugger running in active state and going off and leaving a
system hung up at max CPU load for hours. To test server reliability,
you have to also test on an active server, folks. I do. These
errors are *NOT* what the average user will ever see. But they
*DO* happen and they are painful. Yes I can restore a full
8-9 Gig test server from tape with over 60,000 files on it. No,
I don't like doing it and you always wonder .. Sometimes when I ask
a tape system to rebuild a big one like this that old Black
spiritual I used to sing in the High School chorus rings back ..

"I wonder as I wander out under the sky, If .. "

In theory, it really is only bad programming to release any code
which can permit CPU dominiation or fail to yield time slices to a
poll killer application such as TAME .. However, because of the
fact that we can't control the literally millions of Intel Classic
CPU, as I have been educated carefully by my Industrial CPU card
engineering vendor, the damage risk from releasing code which can
cause CPU max and lockup, isn't acceptable at all.

Their most visible system lockup problem they had to solve over
all this happened to be the Rockwell-Collins world-wide voice comm
server system for the USAF, including all the secured communications
for Air Force One, so noted to me! The problem is *NOT* limited to
DOS-VDM's, the PowerBASIC IDE, applications that use INKEY$ written
in PowerBasic... grin. This one was a total native OS/2 32 bit full
pre-emptive multi-tasking system! Very huge grin here.

Those of you who are designing any PowerBASIC application which
uses this technique of INKEY$ for keyboard I/O simply need to be
aware of the issue and again it is *NOT* a fault of PowerBASIC,
in any pure sense of the word at all. Nor is it of any importance
at all if you are the only one using what you write and can control
the system in such a way that polling is not relevant.

But we badly need a fix for the general problem which is better
than the little assembler routine I posted.

And ... sigh for Dave too..

I tried your suggestion without any protection from OSTSR or TAME
in a DOS-VDM session in OS/2 ...

BLAM!

Humor here! 'You have just been attacked by a level 9 key troll!'

He has stolen your CPU!

The problem is still the same

If you simply remark out in your subroutine:

Code:

 
  SUB Screenthings
  '       LOCATE 12+13*RND,1+79*RND
  '       PRINT CHR$(64+16*RND);
        END SUB

You see the why right in that very SUBROUTINE, we need SOMETHING
like the assembly snip I suggested. Without some form of TAME
or OSTSR or other poll troll killer utility, we are right back in
the same gorry poll slicendicer that kills us...

I've been begging for help from PowerBASIC for this one ever
since I bought PB 3.5 when it first came out.

Tom's remark is *VERY* important and *VERY* much appreciated.

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

**Lance Edmonds** · 8 Jul 2000, 08:12 PM

I don't think this will help the OS/2 population, but under Windows, the following code releases the current time-slice to Windows and drops the CPU utilization to almost nothing:

Code:

...
WHILE ISFALSE INSTAT
  IF ISTRUE BIT(pbvHost,8%) THEN
    ! push DS
    ! mov AX, &H1680
    ! int &H2F
    ! pop DS
  END IF
WEND
A$ = INKEY$
...

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

**Mike Luther** · 10 Jul 2000, 06:45 AM

Lance!

I don't think this will help the OS/2 population, but under Windows,
the following code releases the current time-slice to Windows and
drops the CPU utilization to almost nothing:

What a misquote! Hugh grin - GDRFC!

It works in OS/2 DOS-VDM's as well! I just tried it in in one and
the CPU utiliization is slam at the bottom! That's true even
without *ANY* polling dampers!

To get a Handel on things ...

Hallelujah, Hallelujah.Hallelujah ...

NOW!

What are the chances of getting this into even the next fixme for
PB 3.5's IDE and the PB 3.5 PBD interface? That way I can leave a
critical piece of code work *LOADED* when pager goes off and I have
to scram, instead of dump the whole project down and start over with
all the debug pointers and settings!!!!!

Of course I could take the quote another way about us
poor OS/2 users too ... but ...

Given time and money .. I guess anything can be solved
that ain't mortal...

Thanks for your post. I know it's been made before, but I'm guilty as
much as anything else for being a stubborn member of the species. As
first read I azoomed something I shudn'tof.

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

**Fred Katzel** · 10 Jul 2000, 09:55 AM

Thanks Mel & Jerry for your first two replys to my request for
help I combined your two procedures. The only problem that seems
to arisen is that when I capitize a letter a blinking cursor appears
on the line below as well as blinking cursors are appearing on the
working line. This there some way these two problems could be addressed.
Fred K

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

**Jerry Fielden** · 10 Jul 2000, 07:48 PM

Fred

I didn't have any problem with it when I tried it out, but
I didn't combined the Two.

There is better Examples than the one I posted. Did you try
the one Dave Stanton posted?

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

**Roy Petrie** · 17 Jul 2000, 03:13 AM

Lance

Re your code snippet as follows:-

WHILE ISFALSE INSTAT
IF ISTRUE BIT(pbvHost,8%) THEN
! push DS
! mov AX, &H1680
! int &H2F
! pop DS
END IF
WEND
A$ = INKEY$

Does it need to be used in conjunction with INSTAT and if so what
is "pbvHost"?

Can it be incorporated in an Interrupt call? Presumably Interrupt
&H2F with &H1680 placed in the AX register.

I've searched the Internet for a few days now and can find little
reference to Interrupt &H2F. Could you possibly explain (briefly)
what your code is doing?

TIA
Roy Petrie
[email protected]

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

**Lance Edmonds** · 17 Jul 2000, 04:04 AM

Simply put, the code loops until a keypress is detected (INSTAT becomes true).

However, within the loop, the code calls the "multiplex" interrupt (&H21) with AX=&H1680 which asks Windows to reliquish the remainder of the time-slice for the VDM (Virtual DOS Machine).

pbvHost is an internal PowerBASIC variable that "describes" the host environment that the code is running in... bit 8 is true if Windows is running. Unfortunately bit 8 does not detect Windows 2000, but Windows 2000 does respond to the INT &H21|AX=1680 call, so I usually add an additional test in there to cater especially for Win2K...

Code:

IF Environ$("OS") = "Windows_NT" then IsNT% = -1 ' elementary way to detect WinNT... there are other ways!
...
WHILE NOT INSTAT
  IF ISTRUE BIT(pbvHost,8%) OR ISTRUE IsNT% THEN    
...

BTW, pbvHost is documented in the on-line help.

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

**Roy Petrie** · 22 Jul 2000, 11:41 PM

Lance

Thanks for that, worked a treat.

As this thread switched to concern about CPU usage I benchmarked
INSTAT and INT&H2F on my PC at work with the following results
(all tests under the same conditions).

PB35 with only an "Inkey" loop
CPU hits 51% on launch and after 6 secs falls to 0%

PB35 with INSTAT and "Inkey" loop
same result

PB35 with INSTAT and INT&H2F
CPU hits 16% on launch and after 1 sec falls to 0%

PBCC20 with "Inkey" loop only
CPU hits 54% then oscillates between 34% and 54% never falling to 0%

PBCC20 with INSTAT and "Inkey" loop
same result

The Interrupt clearly makes a huge difference whereas INSTAT makes
no difference to CPU usage in either programme.

Regards
[email protected]

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

**Lance Edmonds** · 23 Jul 2000, 06:10 AM

This is off topic for this forum, but in PB/CC (for Windows), you release the current timeslice by using a "SLEEP 0" statement in the loop. However, PB/CC provides a much nicer and cleaner way to achieve this task:

A$ = WAITKEY$

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

Announcement

Cursor for INKEY$

Cursor for INKEY$

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment