Subj : Interrupts
To   : Nick Andre
From : Mike Luther
Date : Thu May 03 2001 04:03 pm

Nick, I used this toolset for years.

NA> Hi...
NA>
NA> I have two questions about programming for OS/2.
NA>
NA> First, what is the DOS interrupt to give up
NA> timeslicing back to the OS? I think its 2F, but can
NA> someone tell me for sure? And when specifically should
NA> a timeslice be given back to OS/2? (keyboard idling,
NA> etc?)

Instead of working at it this way, I think you will be better served by giving
a look not only at this, but the TAME330 utility, or one like it.  It works for
most, but not all applications to bust up CPU bashing.  At least do that for
learning's sake first as well, OK?

For example, before I started fooling around with assembler code to break it up
in my actual programs, TAME330 took care of everything I ever threw at it via
the M/S Bascom PD7 package.  I had *LOTS* of code in it, actually over 750,000
lines of source.....

NA> And second, I have MS-PDS 7.1 (QuickBasic), which can build both DOS and
NA> OS/2 applications. It works wonderful, except for some
NA> reason I can't perform ANY "low level" operations if I
NA> want to compile for OS/2 (ie. poking around in memory,
NA> calling interrupts, etc). I think there is a way
NA> around this in the BC compiler (or possibly the
NA> linker?) but does anyone know why?

Aha!  We are now on the same wavelength here, officially!

Some of the operations that are provided in DOS are not enabled in OS/2.  I
never continued toward native OS/2 applications with it.  The reason for that
was that things I distribute had to be Y2K certified.  There was no way to
stand on that toolset for that reason.

I still have all the hard bound docs for the toolset.  I think if you read the
reference guide carefully, you will find that certain functions are not enabled
in OS/2.  Unless I miss this, for example, I think you will find that the
direct port communications functions OUT and INP do not work in the OS/2 side
of the house.  Nor does anything else that makes direct use of the hardware
ports, although there were cross platform communications functions for things
like using the serial ports with file management techniques.

You could, indeed, and I did, as I recall, splice in assembler coded low level
comm port operations via linking custom libraries to them.

I never, therefore, went beyond the low-level assembler stuff I managed to
write which worked in DOS as well.  I figured that when time came, I'd still be
OK porting it all to OS/2.  But when the Y2K game hit, and I realized that
there would be no further way to upgrade to anything with PD 7.1, I looked for
another DOS solution.  That just to get me through Y2K.

That move produced a decision, based on the time it would take and the Y2K
deadlines, to at least temporarily use PowerBASIC as a substitute for PD 7.1 so
I did that.  It has actually taken until this time to move everything there ..
now a total of over 1,200,000 lines of source covering over 110 full
inter-related executables and major common library modules in PB 3.5.

Of course I'm still stuck with what to do on moving to native OS/2, so where I
really wanted to go, C++ in Watcom, has been waiting in the wings. Presently,
I've managed to write a complete translator from about 138 off the 210
functions we use in PB 3.5, very much like BC 7.1, to Watcom C++ version 11b.
That enroute to IBM's Visual Age for C++.. as well.  Either way I can get to
OS/2.  But with VAC++ I can also get to LINUS/*IX if I must.  I probably, like
it or not must .. groan.

The number of lines in the suite will likely, from early research in the
translator, grow to about 4,000,000 lines in C++ .... gloom.

From all this has come an assembly language snipset that I now use in the
PowerBASIC compiler operations to give me time slice control in every program,
as it now stands.  The PowerBASIC compiler has a very easy to use in-line
assembler interface, much like you can use with PD 7.1 ..

Here's how it looks in PB 3.5 code.  I think if you look at it, you can likely
adapt it to PD 7.1.  That just *MIGHT* get you where you want to go in native
16 bit OS/2 as well.  Hence the long pig trail to here!

>      IF ISTRUE BIT(pbvHost, 8%) THEN '   In WIN environment >         ! push
DS
>         ! mov AX, &H1680
>         ! int &H2F
>         ! pop DS
>      ELSE '                      Not in a WIN environment >         ! push DS
              ; Save DS for PowerBASIC >         ! mov AX, &H8600         ;
Place function $AH68in AX >         ! mov CX, &H00           ; Use less than
1000 MS delay >         ! mov DX, &H0A00         ; Try &H0A00 for a delay in DX
>         ! int &H15               ; Call timer interrupt
>         ! pop DS
>      END IF

In PowerBASIC I learned it is necessary, and safer for sure, to save the DS for
the compiler return.  I never did that in M/S code.  It may be useful even in
BC 7.1 I think.  As well, the internal function for pvbHost is a product
specific internal function for PowerBASIC which does the above job of detecting
whether the box is operating in a WIN environmnet.  That snoop lets you safely
operatine in the &H2F mode you are seeking, I think.

I suspect that if you look at Ralf Brown's interrupt list site, you can find a
non-PowerBASIC function that will let you determine if you are in WIN or an
OS/2 environment, which the above does *NOT* address.  I know there are several
ways at low level to do this.

If you get the TAME320 or TAME330 utility, which I think is on HOBBS, I think
you will get all the help you need on identifying which polling monsters for
which you should provice.  The keyboard is the most obnoxious in my estimation.

But note!

To this very day I have *NEVER*, using any combination of third party
tools,ever been able to break the PowerBASIC IDE of sucking eggs with the CPU.
Never .. ever .. no never .. NEVER.

To that extent, be careful on the old classic Pentium CPU chips.  Any
application you distribute or run on them that maxes the CPU out, can trigger
the F0 bug gambit.  I've had PowerBASIC reduce my OS/2 hard disk to rubble
twice, forcing a complete tape rebuild, just from accidentally leaving it up
overnight running the IDE while four other sessions were doing DOS port
applications and all writing and cross-writing to the hard disk.  I fell asleep
and let PB 3.5 sit idle trashing the CPU on a classic P-box.


Cheers ..


Mike @ 1:117/3001


--- Maximus/2 3.01
* Origin: Ziplog Public Port (1:117/3001)