.fo off
This is file: 07_95QA.TXT

This file contains questions asked of the Driver Development Support Center
(DDSC) and the answers given to that particular question.  Entries are
appended to the top, so the most recent entry is available first.

Each entry starts with a header line that has a KEY WORD (or words) included
to allow the reader to "search" on KEY WORDS of particular interest.  Each KEY
WORD starts with the exclamation point character (!).  This allows for search
arguments that will limit matches to the header lines.

The following KEY WORDS are supported in this file.

KEYWORD                      DEVICES/TYPES OF QUESTIONS
===========   ==========================================================
!BASE         Loader, Memory Management, Strategy/Architecture
!I/O          Serial/Parallel, Pointing Device, Trackball, Keyboard, Pen
!MULTIMEDIA   Motion, Sound
!NETWORK      LAN,
!OTHER        PCMCIA, APM, Miscellaneous
!PRINT        Printer, Scanner
!STORAGE      DASD, SCSI, Tape, CD-ROM, ASPI, IFS
!VIDEO        VGA, SVGA, XGA, 8514, Display
**********    Entry separator (10 *'s)
==============================================================================

!I/O____________________________________**********
July 03, 1995
QUESTION: (Ref: HT8)
I want to set up an interval timer as a watchdog in a driver for a polled
device.  The idea is to poll a port for information, check to see if a
watchdog timeout has occurred, and, given that the timeout has NOT happened,
start the timer interval over again from zero.  (The timer interrupt service
routine simply sets a flag saying that the timeout has occurred.  It is up to
the polling loop to check the flag.)

The documentation does not clarify whether or not DevHelp_TickCount starts the
interval over again when called repeatedly -- only that the last received
interval specification (n, the number of ticks per interval) is the one that
is used.


ANSWER:
The document (PDD Reference) clearly clarifies that "Multiple tickcount
requests can be issued for a given timer handler, but only the last tickcount
setting will be in effect".

For instance if you set the initial TickCount value to a very high value and
then immediately change the TickCount value to a very low value your Handler
would get called after a short interval as the previous large time interval is
overwritten.

Refer:  Physical Device Driver Reference, Ch:  Device Helper Services, Sec:
TickCount


FOLLOWUP QUESTION:
We realize that the tickcount replaces the old time.  We were interested in
whether the interval is restarted from scratch.  For example, assuming a
tickcount equal to 32 milliseconds.  If I call the timer handler with a
tickcount of 1 and after 16 milliseconds, reset it to 2, will the total time
waited be 16 + 64 milliseconds or 16 + 48 milliseconds.  In other words, does
the device driver reset the interval to wait the entire interval or does it
just wait for the remaining time of the current clock tick.  This normally is
not important except when waiting for 1 or 2 clock ticks.


FOLLOWUP ANSWER:
The device driver resets the interval to wait for the entire interval
specified by the last DevHelp_TickCount before calling the timer handler and
not just wait for the remaining time.

1 Tick = 32 ms
TickCount (1)
after 16ms,
TickCount (2)
The total time waited will be (32+32)ms (from the instant TickCount(2) was
called)
From the instant TickCount(1) was called the timer handler would be called
after (16+64)ms.




!VIDEO__________________________________**********
July 03, 1995
QUESTION: (Ref: HS7)
What is the trick to get the selective install and/or the display install
utilities to correctly identify the installed display device?

From our version of SCREEN01.SYS, we are correctly identifying our display
adapter and return our adapter ID (16) when requested.  However, once our
drivers are installed, if you try to run selective install, it displays the
primary display as being an XGA.  If you then click on the primary display
button to bring up the adapter list, it will correctly highlight our display
adapter.

We see a lot of problems when trying to install additional printers and other
components when our drivers are installed and selective installed is used
because our drivers are not part of the WARP installation CD.  Are there ways
around these problems?  i.e.  A better way of handling installation that will
allow selective install to function properly when our drivers are installed.

In our .DSC file, we are using VGA as the type key string because even though
we are identifing and returning our adapter ID from SCREEN01.SYS, if we specify
SVGA then the VGA driver will be highlighted instead of our driver.


ANSWER:
Please refer to the section on Installing and Configuring Display Device
Drivers in Chapter 10 in the Display Device Driver Reference.  There are new
features in DSPINSTL that are not documented in this chapter so I will try to
explain them.

The .DSC section for standard display types.  The standard display types are:

   MPA
   CGA
   EGA
   VGA
   8514
   XGA
   SVGA
   OTHER

The fields are used for detection purposes.  There are several ways an adapter
is recognized, but for SVGA the detection is coded into the screen01.sys
driver.  If the screen01.sys driver recognizes the SVGA adapter, then it
returns information about the adapter.  The fields it fills in are:

look in h\svgadefs.h file.
typedef struct _OEMSVGAINFO
{
    USHORT  usAdaptertype;        //manufacturing code
    USHORT  usChipSet;               //chipset of adapter
    ULONG      ulMemory;               //amount of video memory
}  OEMSVGAINFO;

There are three fields in the .DSC file

* type key
"SVGA"

* additional parameters
"2"

* additional parameter 1  (Manufacturing code = 8 for S3
"8"

*  additonal parameter 2 (Chipsets supported by driver)
"4 5"    //look in svgadefs for manufacturing code of 3 and the corresponding
         //chipsets defined as 4 and 5.

Dspinstl uses the information returned by screen01.sys and matches this
information with the fields above.  For example if screen01 returned:

usAdapterType = 3
usChipSet= 5
ulMemory= 1mg   //need at least a 1/2 mg of memory to run SVGA drivers and
               //1mg to run them in high resolution.


This information would match the .DSC file above.

Another example if screen01.sys returned:

usAdapterType = 3
usChipSet= 6
ulMemory= 1mg

The logic is as follows:

If there were two matching .DSC files, both have a manufacturing code of "3"
for S3 and neither of them had a Chipset of "6" for a chipset match.  There is
too much ambiguity for dspinstl.exe to select either one of them.  So
dspinstl.exe will select the safe .DSC file match (ie.  SVGA dumb frame buffer
driver - pssvga32.dsc file).

If there was only 1 matching .DSC file (matching on the manufacturing code) 3
for S3 and the chipset returned by screen01.sys doesn't match in the .DSC
file, then we assume it will work and highlight it.  I don't like making this
assumption but the video group said this should be okay.

In summary, the chipset in the .DSC file is a more granular approach to
identifying the right SVGA driver that will work for a particular chipset.
Manufacturers come out with many different kinds of S3 boards and only certain
drivers will work with certain chipsets.

The .PMI file is specific to the adapter and chipsets for an SVGA card.  The
.PMI file is usually generated during dspinstl and is not used for detection
purposes, but used by the driver to manipulate the hardware.

Look in svgadefs.h file in the DDK or pull it off the build tree in
h\svgadefs.h.  This file contains information about manufacturing code defines
as well as chipsets.

Also, the information in Chapter 10 that indicates that an additional
parameter for SVGA is required to be 1, is outdated.  It can be either 1 or 2.
In other words, the .DSC file could have 1 additional parameter (manufacturing
code) or 2 additional parameters (manufacturing code and chipset).  The former
is used for backward compatability with older .DSC files.  I recommend always
using the chipset in the .DSC files for SVGA for more granularity in SVGA
detection.

Basically, the additional parameter for SVGA could be either 1 or 2
(manufacturing code and chipset information).  The Type Key should be "SVGA"
Chip set values 0 - 2FFh and FFF0 - FFFF are reserved.  So you should return
Chipset ID, excluding these values.




!BASE___________________________________**********
July 03, 1995
QUESTION: (Ref. HS2)
I like to break up my driver to two separate drivers to load the same memory
mapped card.  In the init portion of each driver then I have to allocate a
selector and perform a PHYSTOGDTSEL, then makep( ) to get a pointer and offset
for the memory mapped card.

1. Will OS/2 have any problem with the fact there are two selectors assigned
to the same memory mapped card during the init time?

2. And as long as I synchronize my drivers so the won't try to write to the
card at the same time, will there be other problems at the task time?


ANSWER:
1) You could have two GDT selectors assigned to the same memory mapped card
without any problems.

2) If you synchronize your drivers so that they do not try to write to the
card at the same time, things will be fine.




!PCMCIA_________________________________**********
July 03, 1995
QUESTION: (Ref: HR9)
I am developing a PCMCIA client driver.  If my client's PCMCIA card cannot be
configured upon insertion, I would like to give the user some feedback as to
why.  Similarly, I may wish to give the user feedback on a successful
configuration.  In either case, the "Plug and Play for PCMCIA" dialog box does
not allow for the information I wish to pass to the user.  I am talking about
AFTER INIT time.

1. Is there any method for allowing a PDD (my client driver) to display a
popup message?  (I'm talking about the type of popup one gets by doing a "DIR
A:"  on an empty A:  drive.)

2. Is file I/O possible at all at ring0?

3. Could I use a context hook to call functions such as DosOpen, DosRead,
DosWrite, and DosClose?  I would use this to generate an error log file as an
alternative for displaying a popup.


ANSWER:
1) We are not aware of any method for allowing a PDD to display a popup
message.  However, you could develop a R3 daemon which will communicate with
the PDD via DosDevIOCtl and display a popup message at the appropriate time.

2) File I/O at R0 is not possible.

3) Context hooks also run at R0.  The context hook run right before the
current thread of executation is about to exit from kernel back to application
(user) space.  So calls - DosOpen, DosClose,DosRead,DosWrite cannot be used.
However, you could do one of the following :

    (A) Develop a VDD which talks to your PDD. The VDD can issue VDHOpen,
        VDHClose,VDHRead,VDHWrite calls for file I/O. After INIT of your PDD
        send a message to the VDD, which in turn can do the file I/O.
        Ref : VDD reference
        Ref : Ch - 9, section on "Establishing PDD-VDD link" in "Writing OS/2
              2.1 Device Drivers in C", By Steve J. Mastrianni.This book is
              available as part of DevCon DDK V1.0, V2.0

    (B) Alternative scheme suggested -

                         DosDevIOCtl
      Device Driver  <---------------->  R3 Daemon
                                               *
                                   Write        Read
                                               
                                         *      
                                 ------------------
                                 |    F I L E     |
                                 ------------------

Data read by R3 daemon (via DosRead) from file is passed to DD in the data
buffer of the IOCtl request packet.

Data to be written to the file is passed in the data buffer of the IOCtl
request packet to the R3 daemon.  The R3 daemon then issues DosWrite.

Since DosRead/DosWrite cannot be issued from R0, we have this indirect
approach.  Extra drag is certainly present due to ring transitions (R0 <-->
R3).

Ref: For details of DosDevIOCtl call refer to Ch-2, Control Program
Programming Reference, section on DosDevIOCtl.




!MULTIMEDIA_____________________________**********
July 03, 1995
QUESTION:  (Ref: HR3)
Can an application send only one buffer greater than 64K?  AUDIO_LOAD ("all
73K of the file", flags = LOAD_START | LOAD_END ). If the answer is true, how
can the driver manage this buffer (greater than 64K) with a 16:16 pointer?  In
other words, how can the 16 bit driver get the following selector?


ANSWER:
A 32-bit application can allocate a buffer of more than 64K and pass the
starting address of the buffer to the PDD via the IOCTl interface.  There is
no problem with that.  If the device driver is 16-bit, it cannot handle buffer
sizes of more than 64K at a time.




!OTHER____________________________________**********
July 03, 1995
QUESTION: (Ref: HR2)
1. Using DDK 2.00, I tried to build the VDDs in SRC\VDEV\VVIDEO.  Nmake halted
when the assembler was working on vv8514io.asm, because the file includes
VV8514p.inc, which doesn't exist.


ANSWER:
1. The file VV8514P.INC is available in DevCon DDK V2.0.  It can be found in
ddkx86\dbcsdd\src_dbcs\vdev\vvideov directory.




!OTHER__________________________________**********
July 03, 1995
QUESTION: (Ref: HR1)
We are writing device drivers for internal use and we are using the Microsoft
C6 compiler provided with the DDK.

We have a need to assign compiled driver modules to various segment names
(other than the default provided by the compiler).  We cannot find any
documentation in the DDK that gives the pragmas that are defined with the
Microsoft compiler (the pragmas found in the documentation appear to apply to
the IBM compiler).

Is there a place in the DDK that we have missed or is there some documentation
available that can be purchased?


ANSWER:
The relevant pragma is used extensively in the Resource Manager.Refer to -
ddkx86\src\dev\resource\rsm_h\rmcalls.h

#pragma alloc_text ( textsegment,function1,[,function2],,,,,,,,, ) The
alloc_text pragma lets you name the segment in which particular functions are
allocated.

#pragma same_seg ( variable1,[variable2],,,,,,,,,,,, ) The same_seg pragma
provides information the compiler can use to generate better code by assuming
that the specified variables are in the same segment.

These pragmas are documented in the Microsoft C Manuals.




!VIDEO__________________________________**********
July 03, 1995
QUESTION: (Ref: HQ0)
I'm working on the installation of our display driver.  I have some questions
about install, some that are specific to our hardware and some that are
general.

Q1. Our product is a chipset (unified memory architecture) that enables the
    user to share memory between the system and the frame buffer.  This means
    that the amount of memory available for the frame buffer may easily change
    after driver installation (a simple CMOS reconfiguration and reboot)
    without a change of hardware.  Our chipset provides SVGA compatibility (our
    SVGAUTIL will use the VESA extended mode interface to set all supported
    SVGA modes, generating a PMI file containing the register information).  I
    believe that our .DSC file should name SVGA for standard type.  Does that
    seem right, given my description of our hardware?

A1. Yes, your .DSC can specify a keyword string SVGA, stating that it can
    handle a standard type of adapter.
==============================================================================

Q2. I'm trying to decide if we need an action routine DLL.  We based our driver
    on the P9x00 driver, which was an SVGA-source based driver, modified for
    multiple-resolution support.  Our old installation files did not use an
    action routine DLL and I didn't intend to include one now.  I plan to
    include the SET_RESOLUTION command in the DSP file.  I assume that the user
    can later select another resolution from the System Settings folder (which
    will call OS2_PM_DRV_QUERYSCREENRESOLUTIONS).  Is this correct?

A2. Your assumption is correct.  If the action routine is not provided, no DLL
    filename should be specified.
==============================================================================

Q3. In order to keep things simple, we are first developing a dumb frame buffer
    driver, with no Win-OS2 support.  We are not supporting monitor timings or
    refresh rates in the PMI file yet but we want to include that support in
    the future.  Whatever approach we take, we want to use the VideoCFG manager
    in the future.  Despite this, I'm still interested in adding in refresh
    rate support soon.  In DISPLAY.INF, under "Files Required for OS/2 Warp"
    (VideoCfg info), is the statement:

           "Your installation must identify the OS/2 version and copy the
             following files..."

    How do you do this?  I see how the .DSP :FILES command can conditionally
    copy files according to MODE=PRIMARY/SECONDARY/DOS etc.  but how would you
    check for the OS version and conditionally copy files?

A3. You can write a utility program to check the OS/2 version.  You can use the
    DosQuerySysInfo call and interpret the minor and major version field of the
    structure returned.  Depending on the OS/2 version, your program can
    generate the .DSP command (:FILES) to copy the desired files.  This utility
    can be used with the :RUN command.  Ref:  Display driver reference (online
    version in DevCon DDK 2.0), section on RUN command.
==============================================================================

Q4. Rather than provide our own PDD (like XGA.SYS), we make slight modifi-
    cations to SCREEN01.SYS (add in identification for our chipset, modify the
    GetOEMInfo routine and GetManufacturerData IOCtl to return some hard- ware
    specific information for us).  Is there anything special I have to do, in
    installation, because we would be copying a file to the user's system with
    the same name as one he/she already has?  I'd rather not clobber the user's
    SCREEN01.SYS and I'd rather not BE clobbered if he installs a service pack
    later.

Q4. The only solution is to run your Installation Package again after the
    Service Pack Update.
==============================================================================

Q5. Is the source for DSPINSTL available anywhere so that I can get a clearer
    idea of how things work?

A5  The source for DSPINSTL is not available.




!VIDEO__________________________________**********
July 03, 1995
QUESTION: (Ref: HP6)
I am writing/supporting this 16-bit presentation device driver that outputs to
disk an image of a page printed from an application.  This 16-bit presentation
device driver uses the bitmap simulator "DISPLAY.DLL" to render the image on a
bitmap.  I then write this bitmap to a file on a disk.

To implement the BitBlt function, like most other functions, this 16-bit
driver passes the work to the "DISPLAY.DLL"; however, when a color bitmap is
being bitblt'ed to the PS of the DISPLAY.DLL (which is black and white only),
the image appears virtually black on the destination PS.

To attempt to fix this problem, I tried to modify the color bitmap before
passing it on to the DISPLAY.DLL.  In my 'BitBlt' handler, I do the following:

  1. select the color bitmap into the DC of the DISPLAY.DLL, save the current
     bitmap of the DISPLAY.DLL's DC
  2. read the content of the color bitmap,
  3. modify it,
  4. write it back to the color bitmap,
  5. restore the old bitmap of the DISPLAY.DLL, and
  6. pass the modified color bitmap on to the 'Bitblt' handler of the
     DISPLAY.DLL

Is this how one would do it?  If so, I have a problem in step 2 when I try to
read the content of the bitmap (the number of scan lines read is not the
number of lines I asked for).  What's wrong?

NOTE: To select a bitmap into the DISPLAY.DLL, or to read/write from/to it,
I use the functions provided by the DISPLAY.DLL.  The functions are returned
in the dispatch table when I enable the DISPLAY.DLL


ANSWER:
We checked up the 16-bit VGA source, but we could not locate the call
GetBitmapBits. However, the call can be found in 32-bit display driver. In the
description of GetBitmapBits call in ddkx86\src\pmvideo\32bit\eddbgetb.c it is
mentioned that the actual number of scan lines for which data is obtained is
returned (this may be less than what the application requested).

1. From your description, it looks as if you are trying to filter the GRE
calls made to the Display Driver and your filter PM driver is outputting to
disk an image of a page printed from an application.

The GreBitBlt call supports conversion of color data to monochrome and vice
versa by specifying the flOPtions and pBattrs parameters as required in your
application.  Is your filter modifying these parameters while BitBlt is being
done from the application PS to the Display PS?  Ref:  Presentation Device
Driver, Ref for OS/2 under "Mandatory and Simulated GRE Function Reference on
GreBitBlt"

Once GreBitBlt is called by your BitBlt Handler, on return from the Display
Driver BitBlt, you could then use GreGetBitMapBits to transfer data from
Display DC/PS to your Memory DC backed by the appropriate application/filter
bitmap.  You could then copy the appl/filter bitmap back to disk.

So the sequence would be as follows:
- An application initiates a BitBlt xfer from the application PS to the
Display PS/DC.

- Your filter traps the BitBlt call in your BitBlt Handler.  Your filter makes
the required call to the original BitBlt call of Display Driver.  Just check
the values in flOptions and pBattrs parameters.

- Once you get control back from this call do a GreGetBitMapBits to the Memory
DC created by you (backed by the bitmap defined by you).  Ensure you have
defined the BitMap appropriately using BitMapInfo2 parameter.

- Copy the bitmap onto disk as required by you.


FOLLOWUP QUESTION:
In the "Presentation Device Driver Reference", in the "remarks" section of the
GreBitBlt call, you can find the following:

"When copying bits from a color bit map to a monochrome bit map or device,
only those pels that are in the source background color are copied to the
target as background color.  All other pels are copied to the target as
foreground color."

This is exactly my problem, when I print a color bitmap from an application,
the final bitmap is virtually all black because most pels from the source
color bitmap will not have the background color and because the bitmap
simulation "DISPLAY.DLL" that my 16-bit driver uses is monochrome.

1. How can I make the final bitmap to have ditherings such that the image
still looks decent even in black and white?

Also in the same section you will find the following:

"Note:  The device driver may pass back Bitblt calls that call for stretching.
However during the stretching, GRE will perform dithering only if the device
supports more than two colors and a bit map format of more than one bit per
pel in its response t o a GreQueryDeviceCaps call.  A driver may alter these
capabilities before returning a Bitblt call to the GRE so that dithering will
(or will not) be done."

2. Can I find an example of this some where?


FOLLOWUP ANSWER:
1) You need to pay attention on the parameter 'pBattrs' and 'flOptions' while
calling GreBitBlt function.  Refer to description of 'pBattrs' - transfer from
color bitmap to monochrome bitmap or device.  Also refer to section on
"support for monochrome devices" in presentation device driver ref.

2) You can refer to minidriver2 source in DevCon DDK V2.0 in the directory
ddkx86\src\prntdd\mdriver2 for the usage of dithering support in GRE220.  You
can also refer to function SetupMonoDither() in ddkx86\src\pmvideo\
s3tiger\eddcdith.c.  Source for dithering program is available in ddkx86\src\
pmdisp\dither.asm




!I/O____________________________________**********
July 03, 1995
QUESTION: (Ref: HP0)
1. Can I use _inp() function call to get data from a I/O port? How?

2. Do you have a sample code for this?


ANSWER:
I/O operations could be done only at Ring 0 (and Ring 3 with IOPL).This could
be possible if you have your own Device Driver handling the I/O Port.

1) Yes, you can use inp() to read data from I/O ports.

2) Please refer to the following sources

ddkx86\src\dev\kbd\ibmkbd\kbdstate.c
ddkx86\src\dev\dasd\ibm\ibm1flpy\flp1ism.c
ddkx86\src\dev\dasd\cdrom\ibm1s506\s506init.c
ddkx86\src\dev\dasd\cdrom\atapi\atapips2.c

inp() is defined in ddkx86\src\dev\dasd\diskh\addcalls.h

Alternatively you could also use TESTCFG IOCtls for I/O Services.This is
documented in the Physical Device Driver Ref.  Cat.80/Fn.0x41 for the IN
instruction.

DosOpen 'TESTCFG$' and use this Handle on DosDevIOCtl.

#define INCL_DOSDEVIOCTL
#define INCL_DOSFILEMGR
#include <os2.h>

typedef struct _ParmPacket
{
  USHORT port address;
  USHORT width;  // 1=byte,2=word,3=dword
} ParmPacket;

typedef struct _DataPacket
{
  ULONG data;   // data read
} DataPacket;

HFILE  filehandle;
USHORT action;

if (rc=DosOpen("TESTCFG$",
        &filehandle,
        &action,
        0L,
        0,
        1,
        0x40,
        0L)) return 1;

if (rc=DosDevIOCtl(&DataPacket,         // Data Packet
                   &ParmPacket,      // Parameter Packet
                   0x41,             // IN instruction - Function Code
                   0x80,             // Category
                   (HFILE) filehandle)) return 1;

(DataPacket.Data) should contain the input value read from the port.




!OTHER__________________________________**********
July 03, 1995
QUESTION: (Ref. HO8)
I have a piece of code that is loaded before OS2LDR.  It must remain in memory
until our BASEDEV=x.FLT is loaded to handle all INT 13h requests.

1. Is there a location in memory where it will be 'walked on' by OS2LDR?

2. Is there a copy of the current DDK documentation available in hardcopy
form?  (I hate on-line docs for new systems).


ANSWER:
1. Load your code at the top of the 0-640K Area and decrement the available
memory by the amount your code occupies. (If your code occupies 2K decrement
available memory to 638K)

2. For a copy of the current DDK documentation, download DDKPUBS.TXT from the
Main File Area.


FOLLOWUP QUESTION:
1. Is there any way that the memory taken up at the top be recovered?  We
expect the size to be about 12kb and don't wish to have that amount consumed
in all VMs.

FOLLOWUP ANSWER:
1. In you DOS Settings, you could still set DOS_RMSIZE to 640K




!MULTIMEDIA_____________________________**********
July 05, 1995
QUESTION: (Ref: HS4)
We are developing a VSD only Audio Device Driver and are seeing some
synchronization problems when playing back video clips with the digital video
player.

For various reasons, we are not currently supporting the DIVE interface in our
display driver.

When we play the short MACAW.AVI clip that gets installed with the MMOS2
subsystem, we are seeing a very large number of skipped frames and the video
playback completes before the audio by over 1 second.

When we play back one of the longer clips on the WARP CD, the synchronization
is much better but still a little off.

We have been unable to determine why the synchronization is so far off.  It
does not appear as though the digital video player is enabling any events and
the MMTIME we return when we complete each audio buffer is correct.

Other than the synchronization issue, our audio driver seems to be working
fine in all other aspects.

1. Do you have any ideas as to what could be causing the synchronization
problem?

2. Also, can you explain how the digital video player performs synchronization
with the audio stream?

ANSWER:
1. The synchronization problem may be due to the following factors :
   - processing power of a CPU
   - throughput of a data storage
   - efficiency of the display subsystem.

The above factors affect the playback of a video.

Ref:  MMPM/2 Device driver Reference, Ch.  - Ultimotion Data Stream
Specification Sec.  - Playback characterstics.

2. Refer to the section on " Audio and Video Synchronization" in the same
manual.(Ch.  - PDD Sample for MPEG Video Playback Devices)

3. Ensure that the MMTIME reported is correct.




!OTHER__________________________________**********
July 05, 1995
QUESTION:  (Ref: HT5)
I've built the PCMCIA sample device driver included in the April '95 DDK.  It
can be found in the \src\pcmcia\clsample directory using MSC 6.0, MASM 6.0 and
the April '95 DDK.  I have OS/2 Warp installed on a generic 486/DX 66 Mgz ISA
workstation.

When I try to debug the driver, using Persicope/32 for OS/2, I notice that I'm
unable to step thru the INIT COMPLETE portion of the driver.  I have added the
statement INT3() right after the case CMD_INIT_COMP:  statement in CLSAMPLE.C.
I can debug thru the StrProc portion of the code, including the RPINIT
processing.  Upon returning from the INIT processing, I would expect a return
to the Kernel, followed by a return call to the driver to process the init
complete request packet.  However, the driver just continues to load and no
futher breakpoint processing occurs.

The driver is written in C and Periscope/32 permits source level debugging of
both the C and Assembler code.


ANSWER:
The INIT_COMPLETE request packet is sent by the kernel after all the PDDs have
been loaded and initialized.  This command is sent to the device driver only
if it is a level 3 device driver and if bit 4 is set in the capability bit
strip in the device header.  Although CLSAMPLE meets this requirement, check
the offset 0x1A into the device header to check if bit 4 is set or not.  You
could check this bit before the init(rp) routine is executed to see if the
generated code is proper or not.  After the init(rp) routine is executed, you
can also check this bit to verify that the init routine is not corrupting the
bit.  If this bit is not set, the kernel will not call the INIT_COMPLETE
routine.  You could also trace using the kernel debugger.  Ref:  PDD ref, Ch -
physical device driver strategy commands, section on INITIALIZATION COMPLETE.

In CLSAMPLE.H change the CS_REVISION to 0x105 for WARP.




!STORAGE________________________________**********
July 05, 1995
QUESTION:  (Ref: HU4)
At this point in time, I'm trying to stay away from specific device driver
development.  Our disk array product, which is host independant, will
interface to any SCSI host adapter.  Therefore, my goal is to not write a
device driver but connect to any .ADD in the system.

What I do need, however, is to write an application, an array manager, to
interface to the driver set.  Here is an example block diagram:

        -----------------
          Array Manager
             OS/2 App
        -----------------
               |
               |
        -----------------
          Driver Layer
          OS2SCSI.DMD
              -or-
          OS2ASPI.DMD
        -----------------

I am investigating using either ASPI or talking direct to the SCSI DMD layer.
Unfortunatly, neither is comming easily.

My problem is associated with the DDk v1.0 CDROM source code.  Included in the
CDROM as part of the online documentation but NOT included as installed src,
is code to develop ASPIDRV.SYS.  I copied the code out of the online manual to
files.  Unfortunatly, using MSC6.0, it does not compile.  I get several dozen
compilation errors -- some of the errors are just syntax bugs but the errors
are too many to mention.

1) Do you have an updated source set for ASPIDRV.SYS?

My goal is to write my array manager OS2 APP to pass ASPI-packets to the
device.  OS2ASPI.DMD ships with OS2 but it looks like I need to supply
ASPIDRV.SYS to the customer.  That is why I am attempting a compilation,
albeit unsuccessfully.

2) Any suggestions?  Is an updated ASPIDRV.SYS source code available or one
NOT in the documentation file, but actual source?

3) Can you suggest any other method of APP->SCSI communication?  Do I have to
use ASPI.  I do need to send CDBs to the device so generic IOCTLs do not have
the ability (I think?)



ANSWER:
1. The only change in ASPIDRV.C would be to change the sequence of parameters
to -

    VerifyAccess(SEL Selector,USHORT Length,USHORT MemOffset,
                 USHORT AccessFlag)

    This would then be compatible with the DDK Library - DHCALLS.LIB
    Besides this, there are no changes.  Neither is an updated version
    available.

    This component is owned by Adaptec and this piece of code is no
    longer in the DDK.

2.  For the actual source, please contact Adaptec.

3. To send CDBs, use ASPI.  The generic Disk IOCtls are documented in the
Physical Device Driver Ref.  and do not have any IOCtls for CDBs.  You could
also refer to the chapter on "Advanced SCSI programming Interface" in Storage
Device Driver Ref on Devcon DDK V2.0.




!OTHER___________________________________**********
July 05, 1995
QUESTION: (Ref: HW7)
We are attempting to debug a NDIS 2.01 Network Driver on Warp 3.0 and have
been unable to find a Debug Kernal.  We attempted to load the kernal off
Volume 6 of the Developers Connection but it said it was an incompatible
kernal.  Any suggestions?  (Through phone call found out customer was using
WARP CONNECT)

ANSWER:
Had customer do a search on DEBUG.DSK on the CONNECT CD and told him to do a
loaddskf on the image to create the installation diskette.




!OTHER___________________________________**********
July 06, 1995
QUESTION: (Ref: HS6)
1. What happens to the thread and the process when "interrupted"?

2. What can cause DevHlp_ProcBlock to be interrupted?

3. Will the thread that called DosDevIOCtl() get control back, or is it
aborted?

4. Why should the sleep be marked as interruptible unless the sleep duration
is expected to be short?

ANSWER:
1) When an interrupt occurs, control is transferred thru the IDT (interrupt
descriptor table) to the interrupt manager's dispatch routine with interrupt
disabled.  Registers of the interrupted context are saved,the system switches
to interrupt mode by switching from current thread kernel stack to global
system interrupt stack.

Interrupt manager's dispatch routine uses the interrupt number as an index
into interrupt table and calls all interrupt handlers chained to that
interrupt level.

If the interrupt context was executing code at privilege level 0, then
interrupted thread was running in kernel mode, since kernel mode is
non-preemptible, interrupted context is resumed directly by restoration of the
registers and return of control to interrupted point.  If interrupted context
was executing at privilege level 2 or 3,interrupted thread was executing in
user mode.  Since user mode is interruptible, a kernel flag is checked to see
whether another thread of equal/higher priority is potentialy ready to run.
If flag is set it implies that another thread of equal/higher priority is
ready to execute so context switch takes place.

Ref :  Design of OS/2, by Deital & Kogen, Ch - 5, section on "Interrupts"

2) A signal such as CTRL-C, process death or some other forced action can
interrupt ProcBlock.

3) The thread that called DosDevIOCtl will get the control back whether the
call is successful or not.

4) The sleep should be marked as interruptible so that you can break the block
by CTRL-C signal.  Otherwise that thread will continue to sleep foreever for
an event with no way of waking it up.


FOLLOWUP QUESTION:
1) If DevHlp_ProcBlock is interruptible, and the sleep is interrupted because
of a Ctrl+C or Ctrl+Break, and the process does not handle Ctrl+C or
Ctrl+Break exceptions so it is terminated by OS/2, does DosDevIOCtl return to
the caller before the process is terminated?

2) And what if DevHlp_ProcBlock is NOT interruptible, and the process that
called DosDevIOCtl gets a Ctrl+C or Ctrl+Break, and the process does not
handle Ctrl+C or Ctrl+Break exceptions so it is terminated by OS/2, and an
interrupt does happen that runs the thread so ProcBlock wakes up, does
DosDevIOCtl return to the caller before the process is terminated?

3) What error code should physical device drivers return when DevHlp_ProcBlock
is interrupted?

4) What standard OS/2 API return code is this error code mapped to?  (other
than for user defined DosDevIOCtl categories)

FOLLOWUP ANSWER:
1. Yes ,the control should return to DosDevIOCtl.

2. You could consider using the DosExitList in this scenario.On receiving
Ctrl+C OS/2 terminates the process,but before it terminates you could wait for
the completion in the ExitList Routine.

3. AL is returned with a non zero value for an unusual wakeup.  The device
driver should then respond by performing any necessary cleanup,setting the
error code in the status field of the request packet,setting the done bit,and
returning the request packet to the kernel.

For the error code to be returned refer to PDD Ref.,Ch.8 - PDD Strategy
Commands Sec.  - Request Packets.

You could use the Error Code 11h - Character I/O Call Interrupted |

Status Code 100h - driver done bit |

Status Code 8000h - error code,if this bit ise set the lower 8 bits define the
Error Code.

Request Packet Status Returned = ( 8000h | 0100h | 0011h )

4. This should map to ERROR_INTERRUPT (95) in the DosDevIOCtl Return Code.
Refer to DDKX86\H\BSEERR.H in the DDK.




!OTHER___________________________________**********
July 06, 1995
QUESTION: (Ref: HU9)
I send absolute mouse coordinates from my touch screen driver to the MOUSE$
driver to emulate mouse coordinates.  When I receive a touch on the touch
screen, I send one absolute mouse packet, with mouse button 1 down AND
movement; on a release I send a mouse button 1 up (I don't have a Z
coordinate).  This provides adequate mouse emulation in OS/2 sessions.

However, in full screen Win-OS/2 sessions, the emulation doesn't work.  One
touch produces mouse movement only.  It seems to take TWO touches in the
identical location to produce a mouse click.  Once clicked, it's impossible (I
think) to generate a button release.

Also, in full screen Win-OS/2 sessions, the cursor movement seems to be scaled
by 2 with OS/2 Warp FOR Windows, but not with the OS/2 WARP WITH Win-OS/2
which was included in the DevCon 6 CDs.

1. What is the proper protocol to emulate a mouse using absolute mouse
movement?  I've tried sending two separate messages for a touch:  first pure
mouse movement, then immediately afterward mouse button 1 down - but then the
first message seems to get ignored.

2. What installed file(s) changed for the Win-OS/2 mouse support to correct
this problem?

ANSWER:
An optional disk is available with MS windows v3.1 DDK modified code which
contains sources for WIN-OS/2 Mouse, WIN-OS/2 Serial & WIN-OS/2 seamless VGA.
The Mouse Code has the modifications that were made to the Windows Mouse
Driver for its adaptibility in an WIN-OS/2 Session.

Also refer to "Building the Win-OS2 Mouse device driver " in I/O Device Driver
Ref .




!PRINT__________________________________**********
July 07, 1995
QUESTION: (Ref: HS0)
I have a slight problem with a minidriver that I am writing.  I installed the
driver onto my test machine and later on wanted to delete it.  The system
cannot delete the driver because it says that there are still jobs in the
queue and I should wait until it is finished.  There are no jobs in the queue
but it keeps saying there is.

I tried to create a desktop icon but each time I try, the desktop closes all
the windows and then reopens them, but no printer icon has been created.

So to cut a long story short - How do I delete this thing?  I can't install
new drivers, or at least one with the same name, so I am in kind of in a jam
right now...

ANSWER:
Hold the Print Queue and reboot.  Then select some other printer driver as the
default printer driver (such as the IBMNULL).  You should be able to
right-click on the mini driver printer icons and select delete.

Alternatively you could also try the following :

- disable the spooler by doing the following
  * Double Click on OS/2 System icon
  * Double Click on System Setup icon
  * Double Click on Spooler, click on icon on left of title bar and select
    "Disable Spooler" menu item.

Then follow the installation procedure after deleting current driver.




!BASE____________________________________**********
July 07, 1995
QUESTION: (Ref: HU5)
I am developing an IDE driver like IBM1S506.ADD in OS/2 but with PCI Master
IDE support.  The questions are follows:

After initialization, the first time the OS calls the "ADDEntryPoint", which
is the entry for OS to assign job to my driver, the limitation of the CS
segment is damaged.

From the Kernel debugger, I can see that the SEGMET:OFFSET of my driver is
from 598:0000 to 598:7b60.  But when the limitation is damaged, the limitation
of segment 598 was 31d8.  Any access to address after 598:31d9 gets a message
of "Past end of segment"

1. Could you tell me how the segment limitation is changed?  How to prevent?

2. Is there any way that I can set a break point on the exact time when the
limitation is changed?

3. If this problem is resulted from my driver, what did I violate?

ANSWER:
1. Before your driver exits from the Strategy "INIT" command processing, it is
supposed to set the field (Pointer_1) to word offset to end of your driver's
code segment as well as set to end of your driver's data segment as well.
Verify if you are setting the offset values correctly in your driver code.

2. You can set a breakpoint using the Kernel debugger at the point at which
you are initialising the Pointer_1 mentioned above in the Request packet and
confirm the limits (exit of the initialisation routine).

3. The problem may be because of improper word offsets for your driver's code
and data segments during the INIT command processing.

You can also refer to s506init.c file containing the routine DriveInit in
\ddkx86\src\dev\dasd\cdrom\ibm1s506 directory in DevCon DDK Ver 2.0




!PRINT__________________________________**********
July 08, 1995
QUESTION: (Ref: HV8)
Our device sits between the computer and the printer attached to a LPT port.
So that we can access the device successfully I am calling the
REQUESTEXCLUSIVE routines inside the print device driver, this is outlined in
the DEVCON News IV "Sharing the parallel port".

I implemented the code from the example into my device driver and rather than
waiting for the port to become free (REQWAIT which is 1), I passed a 0, which
I gather from looking at the source of the device driver means return an error
if the port is busy.

If my program calls my device driver 14 times while the machine is printing to
the parallel port then it returns an error of 20 decimal.  This error code
means the device is in use, but on the 15 call to my device driver the error
code is returned as a 1.

At this point when printing finishes the error code is still returned as a 1
and the only way I can then access the port is to quit my program and start it
up again.  That then enables me to access the port successfully.


ANSWER:
The parallel port device driver source code does not return a 1 as an error in
AX on return from request exclusive access.  You can see this by viewing the
prtpdd_entry, the prtreqexclusive, and checkdirectaccess routines of the
prtplpt.asm module.  This module can be found in the \DDKX86\SRC\DEV\PRINTER
directory of the DDK CDROM.  The AX register is set to an error code on each
exit point and in no case is it ever set to one.

Your note indicates that your application calls your device driver which in
turn calls the parallel port device driver.  Have you debugged path 15 to see
where the one is being set in AX?  Is your device driver making any DevHlp
calls before or after the call to request exclusive access that may be
returning a one in AX?

Clearly, closing down your application and restarting it resets the error
condition.  This action has no affect upon the parallel port device driver.
The parallel port device driver does not receive a close request or any other
command and therefore cannot be changing its behavior (it remains constant).
Your device driver, however, receives a close strategy command when your
application terminates (regardless of whether your application explicitly
issues it).  You may be doing some cleanup here to reset the error condition.
I would suggest you debug your device driver a little closer and this may
solve the problem.




!PRINT___________________________________**********
July 10, 1995
QUESTION: (Ref: HW4)
Is there a way to print variables to the screen or to a file during the task
time?

ANSWER:
There is no devhelp to print variables to screen or to write to a file during
task time.

1. However, you could connect a terminal to one of the COM ports and use
functions defined in ddkx86\mmos2\samples\pastk\commdbg.c to print strings.

2. If you want to print variables to a file, you could develop a VDD.  The VDD
could issue VDHOpen, VDHClose, VDHRead, VDHWrite calls to the file.  From the
PDD you could send info to the VDD.

Ref :  For details regarding establishing PDD-VDD connection refer to Ch - 9,
"Writing OS/2 2.1 Device Drivers in C", Steve J. Mastrianni section on
"Establishing a VDD-PDD Link".

For details regarding VDH* calls refer to VDD ref.

3. You could have a Ring 3 Daemon that talks to your driver via IOCtl to
get/put Messages to a File.

The scheme suggested is -
                        DosDevIOCtl
     Device Driver  <---------------->  R3 Daemon
                                              *
                                  Write        Read
                                              
                                        *      
                                 ------------------
                                 |    F I L E     |
                                 ------------------

Data read by R3 daemon (via DosRead) from file is passed to DD in the data
buffer of the IOCtl request packet.

Data to be written to the file is passed in the data buffer of the IOCtl
request packet to the R3 daemon.  The R3 daemon then issues DosWrite.

Since DosRead/DosWrite cannot be issued from R0, we have this indirect
approach.  Extra drag is certainly present due to ring transitions (R0 <-->
R3).

Ref :  For details of DosDevIOCtl call refer to Ch-2, Control Program
Programming Reference, section on DosDevIOCtl.




!OTHER___________________________________**********
July 10, 1995
QUESTION: (Ref: HW9)
I just want to know if it is possible to have my device driver write output to
the debugging kernel screen.  If so, how.  I was hopeing for a devhlp routine
of some sort, but couldn't find one.  It would be even nicer if the driver
could detect the presence of the debug kernel and turn logging on or off
accordingly.

ANSWER:
1. You could print strings to the debug terminal attached to one of the COM
ports by using functions defined in ddkx86\mmos2\samples\pastk\commdbg.c

2. If you want to print variables to a file, you could develop a VDD.  The VDD
could issue VDHOpen, VDHClose, VDHRead, VDHWrite calls to the file.  From the
PDD you could send info to the VDD.

Ref :  For details regarding establishing PDD-VDD connection refer to Ch - 9,
"Writing OS/2 2.1 Device Drivers in C", Steve J. Mastrianni section on
"Establishing a VDD-PDD Link".

For details regarding VDH* calls refer to VDD ref.

3. You could have a Ring 3 Daemon that talks to your driver via IOCtl to
get/put Messages to a File.

The scheme suggested is -
                        DosDevIOCtl
     Device Driver  <----------------->  R3 Daemon
                                                *
                                    Write        Read
                                                
                                          *      
                                     ------------------
                                     |    F I L E     |
                                     ------------------

Data read by R3 daemon (via DosRead) from file is passed to DD in the data
buffer of the IOCtl request packet.

Data to be written to the file is passed in the data buffer of the IOCtl
request packet to the R3 daemon.  The R3 daemon then issues DosWrite.

Since DosRead/DosWrite cannot be issued from R0, we have this indirect
approach.  Extra drag is certainly present due to ring transitions (R0 <-->
R3).

Ref :  For details of DosDevIOCtl call refer to Ch-2, Control Program
Programming Reference, section on DosDevIOCtl.

4. At the driver INIT time, you could use DosPutMessage - this sends a message
to an output file or device.

We are not aware of any way of detecting the presence of debug kernel from a
driver.




!OTHER__________________________________**********
July 11, 1995
QUESTION: (Ref: HV6)
Is there a bug in the the driver OEMHLP$.  I am getting an error back from the
driver and I know without question the input is valid...  I have validated the
input over and over and have found everything to be in order.

CATAGORY = 0x80
FUNCTION = 0x0b -- PCI BIOS calls


1. My device driver is an 'ADD' driver type -- init. @ load time

2. Connection to the OEMHLP$ driver (IDC) established.

3. First call to the OEMHLP driver returns '0xC' STERR value which in
translation means "GENERAL ERROR DETECTED".

Below is a dump of :

1. IOCTL Request Buffer (RPH -- as defined by reqpkt.h )

2. IOCTL Parameter Buffer

Values above are shown PRIOR to OEMHLP call.

1) Request Buffer values
0030:00005dfe 19 00 10 00 00 00 00 00-00 00 00 00 00 80 0b 22 ..............."
0030:00005e0e 5e 30 00 1c 5e 30 00 00-00                      ^0..^0..B.~]0.N.


2) Parameter Buffer to OEMHLP$
0030:00005e22 01 01 00 00-10 00                               .........@^Po4.



3) Return value
0030:00005dfe 19 00 10 0c 81 00 00 00-00 00 00 00 00 80 0b 22 ..............."
                       |---| error indication value

ANSWER:
If you send a FindPCIDevice with a Device ID that is not present on a
particular system, OEMHLP returns 0x0C as a DosDevIOCtl return code.  Instead,
it should have set the return code in the pci data buffer to a 0x86.

PCI bios return code is not been filled in the data packet when errors occur.
This is a bug with OEMHLP$.  APAR PJ19185 has been created to address this
problem.




!OTHER__________________________________**********
July 11, 1995
QUESTION: (Ref: HY7)
The CLIENT.H file included in the PCMCIA sample has an incorrect definition
for the Request IRQ structure.  The last field, ucIRQInfo2 should be a USHORT
instead of a UCHAR.  The documentation for Card Services says that the
IRQInfo2 field must be 2 bytes.When used as the call to RequestIRQ fails with
a return code of 1B(BAD_ARG-LENGTH) I changed the definition in CLIENT.H to be
USHORT ucIRQInfo2 and the call to Request_IRQ worked fine.


ANSWER:
A defect has been created and will be fixed in the next Release.




!BASE____________________________________**********
July 13, 1995
QUESTION: (Ref. HS9)
We are failing on a call to the devhelp routine LockSeg.

We allocate memory on the stack in a DLL for the DosDevIoctl parameter and
data buffers.  Inside the device driver we read these buffers and verify that
the data we read is valid data.  This works; data is correct in both buffers.
We then call LockSeg; the selector is 157, type = 1 (long term, any memory),
wait = 0 (wait until available).  This call fails.  We then call LockSeg again
(no change to the parameters passed).  This call passes.

Why does the first LockSeg fail and the second LockSeg pass?

ANSWER:
We do not have any Devhelp function called LockSeg.  You must be using Steve
Mastrianni's Library.

But the you can get the real return code from the DevHlp call as follows:

On kernel debugger, just step into through LockSeg code.  You may find the
following ASM code:

   MOV   DL,  DevHlp_Lock            ; setting Lock function code
   CALL  [Device_Help ]              ; calling DevHlp function entry point

 ==> At this point just use "p" as the command

The control will return from DevHelp function.  and if your DevHelp function
fails, the Carry flag is set and the value of AX will be real error code.  If
devhelp function succeeds the Carry Flag is Clear.  The definition of the
error code are defined in DDK\H\BSEERR.H.

Possible error codes could be -

170 - Segment unavailable
6 - Invalid handle

Alternatively you could also try DevHlp_VMLock and let us know if helped.

FOLLOWUP QUESTION:
The error code returned is 5. Viewing from the kernel debugger we noted the
selector being locked had no pagable memory assigned to it, even though we
read the information in the device driver!

In any case we changed from allocating the information on the stack to doing a
DosAllocMem call.  We noted in the Physical Device Driver Reference that this
is required for DosDevIOCTL calls.  This wastes memory but it does appear to
work.

Does it sound like we have solved the problem?

FOLLOWUP ANSWER:
Yes, we feel that your problem is solved.  For details on usage of DevHlp_Lock
on buffers passed via DevIOCtl calls refer to remarks section of the Lock in
Device Helper Services chapter in the PDD Reference.

You could use the OBJ_TILE option with DosAllocMem.This would ensure that the
memory object allocated would be in the first 512MB of virtual address space.




!OTHER__________________________________**********
July 13, 1995
QUESTION: (Ref: HT9)
We have an application that is using VMLock/Unlock to lock a heap that is
managed by DosSubSetMem/DosSubAllocMem.  There is a problem with memory
staying/leaking in the swap file.

The application will allocate and generate a set of data and then using VMLock
calls in our device driver the heap will be locked in 32K chunks.  When the
application has finished using the data it is unlocked using VMUnLock.  and
then freed using DosSubFreeMem calls.  This is repeated every few seconds.
The addresses returned from the Alloc calls have all been verified as correct.

As this application runs the Swap file grows.  Using OS20memu.exe to check on
memory usage it is noticed that there are an increasing number of Private
memory objects with DOSCALL1 as the owner and an inuse size of 32K.  The
address of these objects does not correspond to any of the addresses we see at
the application level.

If the application is run with locking disabled this behavior is not noticed.

We do not do a DosSubUnsetMem because there is still data in the heap that I
need to keep in memory for the next cycle of parts. The heap is not emptied
and removed until the program exits.

I understand that the physical memory gets comsumed when locked, but the swap
file should not keep growing if the suballocations are reusing linear
addresses that were freed the previous cycle.  In the test runs that we have
done the addresses that are returned by the suballocation manager follow a
consistent pattern.

The addresses of the objects that appear in the os20memu display are not
consistent with any of the addresses that I see in the application.

My question is how/why are these memory objects being allocated?  The DOSCALL1
designation as the source of these objects suggests that the suballocation
manager is doing something.

We have used both DevHlpLock and DevHlpVMLock and the swap file still grows.
All of the calls to our diver go through the DevIoctl route.

We started using DevHlpLock 2 years ago with good success, then 6 months ago
we changed part of the application architecture and implemented the heap and
the use of VMLock.

The key question is how are the memory objects getting allocated with DOSCALL1
as the owner?  The addresses of these objects are never returned to my
application.


ANSWER
Use of VMLock would consume Physical Memory because the Virtual Memory
allocated need to be fixed in Physical Memory by the VMLock routine.  This
leads to less physical memory available for other applications and hence the
reason for increase in swapfile size initially.  One of the possibility for
continious growth of swap file may be because Unlocking is not always done for
evey locks done by the application.  Since the application manages the same
memory as a heap, the linear addr for locking is not always the same for the
same 32 K suballocation request.  ( implying that it is not the lock count
which is getting incremented) leading to use of physical memory again.  Thus
leading to swapfile growth.

The only thing we can think of is that Lock uses a SEGMENT number, and
DosSubAllocMem() returns a flat address.  This flat address is NOT guaranteed
to be SEGMENT ALIGNED.  When you call the device driver, passing the 32 bit
flat address, OS/2 converts this to a 16:16 segmented address

What you MAY want to do is use the VMLock Devhelp.  To get the 32 bit FLAT
address passed in unconverted, place it INSIDE the data packet passed in the
DosDevIoctl.  Addresses embedded in the structure are NOT thunked (converted),
as the structure format is unknown to the file system (DosDevIoctl goes thru
the file system cause it requires a device handle).

DOSCALL1 as the owner is because of the DosSubAllocMem() call.

If you look at the 16:16 address does it match any of the DosSubAllocMem()
retuned 32 bit addresses?  To get the 16:16 address use the DosFlatToSel()
function, here is the function prototype.

ULONG _Optlink DosFlatToSel(ULONG);

PVOID x;
PUCHAR16 y;
      y=(PUCHAR16)DosFlatToSel((ULONG)x);

As stated above, one must be careful with the addresses returned from
DosSubAllocMem() as they may NOT be SEGMENT ALIGNED.




!OTHER__________________________________**********
July 14, 1995
QUESTION: (Ref: HR8)
This report concerns the handling of an error condition by OS/2's
implementation of PCMCIA Card Services.  Proper coding in my driver allows me
to avoid this error condition, but Card Services should handle it nonetheless.

From the current PCMCIA Card Services spec (yes, I know OS/2 uses CS level
2.0, but I don't think this detail has changed), the criteria for the starting
address i "on a boundary that is a multiple of the number of contiguous ports
requested rounded up to the nearest power of two.

During my client driver testing, I inadvertently passed a starting address of
0x108 with a range of 16 bytes to Request_IO.  The result was bizarre address
decoding at the socket.  Changing the starting address to a correct value such
as 0x100 or 0x110 permitted proper operation.

I think that OS/2 PCMCIA Card Services should flag a bad starting address and
return a BAD_BASE error (0x03) status on the Request_IO call.

Note that this problem will only occur if the client specifies the base
address going into the Request_IO call.  If the input value is zero, Card
Services assigns the base address itself and returns a properly aligned value.

ANSWER:
A Defect has been opened.  Meanwhile as you have already pointed, you could
specify an input value of 0 in the Request_IO Call.  APAR PJ19355 has been
created for this problem.




!OTHER__________________________________**********
July 14, 1995
QUESTION:  (Ref: HU3)
The situation is this, we are developing an OS/2 ODI driver for a Smart Card
that is based on an 80186EC.  This Card utilizes a Shared Ram Interface
between the PC and the Smart Card.  One of the main requirements of the Driver
is to provide an alternate Command data flow that bypasses the normal Send and
Receive data flows.  Because we used the ODI Specification, the IOCtl
functions are shielded from us and cannot be added to!  So we decided on using
OS/2 system services (IE.  Queues & Pipes).  It appears though that none of
the system services are accessible from the ring 0 driver either in "Kernel
Mode or Interrupt Mode".  None of the documentation that I have specifically
states that Functions like "DosOpenQueue" or "DosOpen" are not allowed from
ring 0!  It does state that a small subset is allowed from the Ring 3
intitialization code.

So My question is, Can we access Queues & Pipes from the Driver?  Either
through some gyration of the DevHlp routines or a call gate?  Even the Event
Semaphore stuff is only from the driver to the calling app not from the
calling app to the driver.

I Went through all of the Q&A stuff on the "Dude" BBS and I went through the
Technical Journal's on the "Dude" BBS.  But none of the documents have any
information on this Subject.  If you could provide some assistance and maybe
some example source Code, I would be grateful.



ANSWER:
You cannot access Queues & Pipes from a PDD since these calls are accessible
only from ring 3.

Normally a Ring 0 application cannot upcall or call a Ring 3 application as it
violates the protection mechanism of the 80386 CPU.  Indirectly, you could
achieve the same effect by having the Ring 3 application spawn a Ring 3 thread
which creates an Event Semaphore, passes the handle to the DD via an IOCtl
call, and then blocks on the semaphore.  Once the thread awakens after
unblocking from the semaphore, the thread could do a call to the required
application code (upcall routine) and then go back to wait on the semaphore
after returning from the upcall routine.

The DD can trigger the semaphore at task time using the PostEventSemaphore
devhelp whenever it wants to initiate an upcall sequence.  In case the upcall
has to be done during an interrupt sequence (interrupt time), the DD can use a
context hook (refer to AllocateCtxHook, ArmContextHook devhelps in PDD
reference) routine to do a PostEventSemaphore for initiating an upcall
sequence.




!PRINT____________________________________**********
July 14, 1995
QUESTION: (Ref: HW5)
We were looking at what we are doing and have the following usability
questions.

Observations:

1) DosWrite and DosWrite provide 16:16 (selector:offset) addresses of the
buffers passed in the calls to the respective device drivers, even though the
buffer addresses are 32 bit process space (virtual/logical) addresses.

2) DosDevIOCtl provides the 16:16 addresses of, not only the request packet,
but the referenced parameter and data packets.  The parameter address and the
data address are both installed in a request packet as 32 logical addresses
during procedure invokation..

Observations 1 and 2 above are true, even if the referenced information does
not reside on a virtual page boundary (4K).  Now, the DosDevIOCtl calls I need
to make to my driver require passing buffers of information from the process
space to the device driver space, too.  Thus, I have the need to convert a 32
bit process address into a 16:16 address for use by the driver, even if the
address does not reside on a page boundary.

Both the DevHelp_VMLock and DevHelp_VMProcessToVirtual calls require the
referenced information to reside on an page boundary.  Since by observation I
can see that it is possible for the address to be converted, how do I do it?

ANSWER:
There is no call by the name DevHelp_VMProcessToVirtual.  we presume you are
referring to DevHelp_VMProcessToGlobal call.  In this call the address range
must be on a page boundary.  You could refer to "GetGlobalAccess" procedure in
ddkx86\src\dev\screendd\svgarout.asm to know how to align to page boundary.

VMLock routine itself rounds the linear address specified down to the nearest
page boundary.  You need not do it explicitly.

In the read/write request packet received by the device driver the transfer
address is a locked 32-bit physical address of the buffer for the data.
Before using this address in the device driver you need to convert this 32-bit
physical address to a virtual (16:16) address using DevHelp_PhysToVirt
call.The device driver need not unlock the address when request is completed.

In the IOCtl request packet the parameter buffer and data buffer addresses are
passed as virtual (16:16) addresses (The system does the conversion from a
32-bit process address to a virtual address).  However the device driver must
lock/unlock the parameter/data buffer segments.

However, the contents of the buffer have to be handled by the driver only.  If
you are passing a 32-bit physical address then before use you need to convert
to virtual address using DevHelp_PhysToVirt.  If you are passing linear (0:32)
address before use you need to convert to virtual address using FlatToSel
macro defined in ddkx86\inc\devhlp.inc.

For a sample source of read/wrote/IOCtl processing in device driver you could
refer to App - C Listings "Sample OS/2 serial device driver" in "Writing OS/2
2.1 Device Drivers in C", by Steve J. Mastrianni (part of DevCon DDK V1.0,
2.0)




!OTHER__________________________________**********
July 14, 1995
QUESTION: (Ref: HW6)
I have been unable to assemble the Super VGA device driver included with
version 2 of the DDK using MASM 6.0.

When I run nmake in the directory \ddkx86\src\vga32\svga256, MASM version 6.0
fails when trying to assemble BITBLT.ASM.  The assembler returns fatal error
A1017:  out of near memory.  I should have plenty of memory in my system (20
Meg of RAM), and I have another 30 or so Meg of disk space available for the
swap file.  I am able to assemble all the 32bit VGA drivers without any
problem.  I can also assemble the retail version of the SVGA256 drivers
without error.  The problem is when I try to make the debug version.

ANSWER:
Remove unnecessary settings from the environment variable.  This is documented
in the USEDDK.INF.




!STORAGE________________________________**********
July 14, 1995
QUESTION: (Ref: HX4)
I downloaded 'optical.sys' from the IBM BBS which had the filename
'21optcl.com'.  I am using this optical driver with OS/2 WARP Connect and an
Adaptec AHA1520 controller PCB.  I wish to connect several optical drives
(both Device Type 0 and 7) to the SCSI bus, however, 'optical.sys' only
supports Device Type 7 devcies.  Since I only intend to connect optical drives
(both Device Types 0 and 7), the best approach would seem to modify
'optical.sys' to recognize both device types.  I did not see the source code
on the DDK.

1) Did I overlook the source code, or do you know where I can find it?

I wish to use 'optical.sys' since it already supports disk ejection and it
would simplify the possible configurations of our systems.


ANSWER:
Optical.sys does support type 0 and 7. You need to add a config parameter to
ibm2scsi.add to get support for type 0. It is documented in the online os2
reference.  Something like:

device=ibmscsi.add /A:0 /!DM:3

where 3 is the scsi id of the optical device, type 0.




!OTHER__________________________________**********
July 14, 1995
QUESTION: (Ref: HX9)
When issuing the Card Services REQUESTWINDOW request(21H) with a Base value
equal to D000, the request fails with a return code of 20H(OUT_OF_RESOURCE).
I have no other cards installed, so there is no conflict.  I also have all the
Card and Socket Services manuals, and they indicate that this condition should
only occur if a previously unshared system range is unavailable.

Code segment follows. board_address has a value of D000.
(code removed for security).

ANSWER:
You must pass a base address of D0000 instead of D000.  Address is a long
value.




!VIDEO__________________________________**********
July 14, 1995
QUESTION: (Ref: HY4)
I downloaded a 16 color SVGA driver off the IBM BBS which appears to work with
the our product, which is medical imaging system.  The file I downloaded was
SVGA16.ZIP which was developed by a Penn State student in a cooperative
education program.  The file was dated from 1993.  However, I wish to use the
driver to display a PAL video resolution (800x768x16) and would like to modify
the source code for this purpose.  How can I obtain the source code?

ANSWER:
This driver (SVGA16) is unknown to us and you really need to contact the owner
of the driver.  The name of the owner is in the readme file.  On the other
hand, you could use the vga32 source code on the ddk.




!STORAGE________________________________**********
July 17, 1995
QUESTION:  (Ref: HR6)
Q1.  Does the source code in the DDK have the required fixes to support
Ontrack Disk Manager?  If so, are the Ontrack changes added into OS2DASD.DMD
or are they added as a filter?

A1.  Ontrack support was added in Warp Fullpack.  Changes were made to
IBM1S506.ADD and OS2DASD.DMD to support Ontrack.  These updates are included
in DevCon DDK 2.0 which has Warp Fullpack source code.  Also, there is a
readme file included with Warp Full- pack which further discusses Ontrack
support.

===============================================================================
Q2.  Is it possible to receive versions of the source code for OS2DASD.DMD
more often than when a new DDK is released?

A2.  There are times when sample code to be included in a future release of
the DDK is shipped to the customer when they cannot wait for the next release
of the DDK.  This procedure is called a RUSH and is done on a case-by-case
basis.  If you need pre-release code, then contact the DUDE; and if sample
code is available we will try to have it RUSHed to you.




!STORAGE________________________________**********
July 17, 1995
QUESTION: (Ref: HV0)

1. RMVIEW /D does not show logical devices or system names under "Driver:
OS2DASD.DMD" for SCSI hard disks with some SCSI ADDs (e.g.  AHA154X, AHA174X).
I've attached a portion of the output from RMVIEW.

2. Is this because the SCSI ADDs are not properly setting the ADD_UNIT Adjunct
data and the OS2DASD.DMD's call to RMADDToHDevice() is failing?

3. Does IBM know of any SCSI ADDs with which this works correctly?

4. Are there any plans to fix this?

5. How about an example of how to replace useage of RMADDToHDevice() with
RMAdjToHandleList() in the PDD.  Is the following correct?  (code removed by
DDSC)

6. The order of RMCreateDriver()'s parameters do not match between the on-line
PDD and RMCALLS.H.

7. Shouldn't RMCreateLDev()'s LDevStruct parameter be documented as an input
in the on-line PDD?

8. OS2DASD.DMD is reporting physical drives A and B as both DSKT_0 to the
Resource Manager as in:

        Logical Device: DSKT_0  Diskette Drive
        Flg:  0000   Class: DASD      Handle: 0XFE475300

        Logical Device: DSKT_0  Diskette Drive
        Flg:  0000   Class: DASD      Handle: 0XFE435398

   cDskt is not incremented in function InitRMInfo() in file DMINIT.C.

Portion of output from RMVIEW /D
------------------------------------------------------------------------------
Driver: IBM1FLPY.ADD  -  IBM Family 1 Floppy Driver
Vendor: IBM OS/2  Version: 1.1  Date (MDY): 9/17/1994
Flag:   STATIC     Type-Subtype: ADDDM - ADD
DMA Channel =  2  Flg =  MULTIPLEXED

  Adapter: FLOPPY_0 Floppy Controller
  Device Type: MS-FLPY        Bus/Width: ISA 8 BIT
  IRQ Level =  6  PCI Pin = NONE  Flg = MULTIPLEXED
  I/O = 0X03F0  Len =   6  Flg = EXCLUSIVE   Addr Lines = 16
  I/O = 0X03F7  Len =   1  Flg = EXCLUSIVE   Addr Lines = 16
  DMA Channel =  2  Flg =  MULTIPLEXED

  Device: DSKT_0 1.44MB Diskette Drive   REMOVABLE  DISK

  Device: DSKT_1 1.2MB Diskette Drive   REMOVABLE  DISK

Driver: AHA154X.ADD  -  Adaptec 154X SCSI Adapter Driver
Vendor: IBM - OS/2  Version: 1.1  Date (MDY): 9/6/1994
Flag:   STATIC     Type-Subtype: ADDDM - ADD

  Adapter: AHA154X_0  Adaptec AHA154X
  Device Type: MS-SCSI        Bus/Width: ISA 16 BIT
  I/O = 0X0330  Len =   4  Flg = EXCLUSIVE   Addr Lines = 16
  IRQ Level = 11  PCI Pin = NONE  Flg = EXCLUSIVE

  Device: DISK_(0,0)  TOSHIBA  MK537FB/         6258      DISK

  Device: CDROM_(4,0)  NEC      CD-ROM DRIVE:841 1.0       CDROM

  Device: TAPE_(6,0)  WANGTEK  5525ES SCSI REV7 3J        TAPE

Driver: XDFLOPPY.FLT  -  XDF Formatted Diskette Support
Vendor: IBM/Backup Technologies  Version: 1.1  Date (MDY): 9/17/1994
Flag:   STATIC     Type-Subtype: ADDDM - FILTER

Driver: OS2DASD.DMD  -  OS2DASD OS/2 DASD Device Manager
Vendor: IBM  Version: 1.1  Date (MDY): 9/13/1994
Flag:   STATIC     Type-Subtype: ADDDM - DM

  Logical Device: DSKT_0  Diskette Drive
  Flg:  0000   Class: DASD      Handle: 0XFE475300

  Logical Device: DSKT_0  Diskette Drive
  Flg:  0000   Class: DASD      Handle: 0XFE435398

  System Name = A:  Logical DASD Volume
  System Flags = 0000

  System Name = B:  Logical DASD Volume
  System Flags = 0000

Driver: OS2SCSI.DMD  -  Non-Resource manager aware base device driver

ANSWER:
1.) See 2

2.)  The Adaptec drivers do not correctly set their ADDHandle prior to
registering devices with the Resource Manager.  This causes searches by
ADDHandle/UnitHandle for these devices to fail.

3.)  We believe this problem is unique to Adaptec drivers.  BusLogic and
Future Domain drivers report disks correctly.

4.)  We will provide you with updated Adaptec drivers that correct this
problem and notify Adaptec.  However, we (OS/2 Development) do not control the
product maintainence policy and cannot predict when a fix would available for
general distribution.

5.)  There are currently no samples of RMAdjToHandleList in the DDK source.
Your example looks correct except that it does not check for a Filter ADD
handle

The routine in the Resource manager that implements the search is:

src\dev\resource\resmgr\rsmsrch.c(RMAdjToNodeListSub)

Try setting a breakpoint at the memcmp in this routine which compares the
adiunctdata you provided with the copies in the resource structures.


6.)  The order in RMCALLS.H is correct.The error in the PDD Ref.  is regretted
and a defect has been opened to this effect.

7.)  We agree.  It looks like the Information Development department assumed
that any P----- structures on the calls were (output) type parameters, so this
problem occurs in a number of calls in the document.  We will have the ID
department inspect the document for this type of error.

8.)  We agree this is a bug, i.e.  on >1 diskette systems the second drive
will also be reported as DSKT _ O rather than DSKT _ 1.




!NETWORK________________________________**********
July 18, 1995
QUESTION: (Ref: HX5)
I have a very strange problem with my PCMCIA NDIS2 network driver that I hope
you can help me solve.

Background:
The driver loads multiple segment (both code and data).  It also has compile
switches to allow either a dos or os/2 driver.  The code is loaded as follows:
(code removed by DDSC)


The assembler is tasm 4.1 for os/2 and the linker is wlink (watcom).  This is
a excerpt from my map file:  (code removed by DDSC)

My problem is this:
The code loads and executes fine.  The requestor starts and network activity
is successfully started.  The first deinsert of the PCMCIA card is handled
correctly.  When the card is reinserted, the code that handles it is located
in the 90h part of the 3090h size of PCODE_GROUP.  At 26a0:3002, I get this
error:

Trap 14 (0EH) - Page Fault 0000, Not Present, Read Access, Supervisor
eax=00000000 ebx=fff00660 ecx=fff0000d edx=00000005 esi=ab80cf88 edi=fe6f0000
eip=00003002 esp=00000f9c ebp=00000000 iopl=0 rf -- -- nv up di pl zr na pe nc
cs=26a0 ss=00e8 ds=26a8 es=0400 fs=03c8 gs=0000  cr2=fcc6d002  cr3=001d3000
26a0:00003002                Page not present
##dg 26a0
26a0  Code    Bas=fcc6a000 Lim=0000308f DPL=0 P  RE    A
##u

The page that comes after 3000h is gone.  The pages for 0 to 2fffh are still
there.

1) What gives?  Why is my page gone?

2) Doesn't the IOPL and PRELOAD link directives lock everything down?



ANSWER:
1) It is possible that the assembler is automatically breaking up the segment.
You could probably use some assembler flag to prevent this.

2) If the code in the segment is used during interrupt time then that segment
needs to be locked.

This could be achieved by getting the selector of a function residing in the
segment during INIT and locking it using LockSeg.  Long term locks should be
used.

fptr = (PFUNCTION) SomeFunction;
codesel = SELECTOROF(fptr);

if(LockSeg(codesel,   //selector
                 1,   //long term lock
                 0,   //wait for seg lock
                 (PLHANDLE) &lock_seg_han_code))  // handle returned
                         return(RPDONE  RPERR  ERROR_GEN_FAILURE);

return(RPDONE);

Alternatively you could use DevHlp_VMLock.

3. Ref :  DevCon News, Vol - 7 , article titled "Writing Device
Drivers:Multiple Segments"

4. You could also try using LINK instead of WLINK.  WLINK generates a map file
that is not compatible with "mapsym".




!MULTIMEDIA______________________________**********
July 19, 1995
QUESTION: (Ref: HV3)
We are developping OS/2 display driver.  There is a problem with playing AVI
File movie.  Our display driver can not support it.  This display driver is
base on OS/2 DDK vga32.

1. What functions do we need to create to play AVI files?

2. Where can we get the information or sample code?

ANSWER:
1. To play AVI files you need to support Software Motion Video features in
your driver.  You should implement following Escape functions:

  DEVESC_GETAPERTURE
  DEVESC_ACQUIREFB
  DEVESC_DEACQUIREFB
  DEVESC_SWITCHBANK

Refer to chapter on S3 display driver, section MultiMedia Hooks in Display
Device Driver Reference for OS/2 on DevCon DDK 2.0 CD.

2. You could refer to the sample code source files:

    eddqesc.c
    eddmdead.c
    cacheman.c

in the directory \ddkx86\src\pmvideo\s3tiger on DevCon DDK 2.0 CD.




!VIDEO___________________________________**********
July 19, 1995
QUESTION: (Ref: HV5)
We are developing a high resolution PM display driver using the S3Tiger
display driver on the DDK as a baseline.  During our development effort, we
encountered following problems, and we need you help to resolve them.

Problem # 1 - We are using OS/2 3.0 (WARP) as our development platform.
Though the driver is developed under WARP, We like to have this driver support
both OS/2 2.1 and OS/2 3.0.

However, when we install the driver on OS/2 2.1, it was not reconized by the
OS/2 2.1 operating system.  The driver has to be RELINKED under the OS/2 2.1
operting system for it to be recognized by the OS/2 2.1 operating system.

Since we do not want to overhaul our entire development environment from OS/2
3.0 back to OS/2 2.1.  Can you show us how to build the driver under OS/2 3.0
which will be reconized by both OS/2 2.1 and OS/2 3.0?


Problem # 2 - We like to provide DCAF (Distributed Console Access Facility)
support in our driver.  Since we do not have a main frame connection in our
facility, we need a DCAF test application which does not require any main
frame connection to test our driver.  Do you have any such application for
testing DCAF support, and can we get a copy of it?


Problem # 3 - We noticed OS/2 3.0 (WARP) has a new DSPINSTL.EXE program for
installing display driver.  Can you provide us with the documentation on what
new features does WARP DSPINSTL.EXE support?

ANSWER:
1. The DevCon DDK Version 1 & 2 - OS2386P.LIB is not compatible with OS/2 2.x
for the Video Drivers.This is primarily because of the restructuring of the
PMWIN,PMGRE & PMGPI dll's in Warp.Consequently,you will not be able to execute
your code on OS/2 2.x with the Warp level (DevCon DDK Version 1/2) headers &
OS2386P library.You could use the 2.x Headers & Libraries for a driver which
will run both on 2.x & Warp.

2. There is no DCAF test application available.  However, you could refer to
the files and documents on \comm\commgr\prodapi\prodaids\dcafsamp on DevCon
Vol 7 Disk 2 for a simple test setup and procedure.  Details on DCAF are also
available on the Presentation Driver Ref.

3. The new features are stricly related to CID installing SVGA display
drivers.  The way to do this is documented in the readme.cid file on disk1 or
look on the build tree in \r207\mri\pminstal\readme.cid.  These features are
not documented at this time.




!OTHER___________________________________**********
July 20, 1995
QUESTION: (Ref: HY0)
I have a minimum feature device driver for a GPIB Interface Adaptor working
pretty reliably but I have run into some problems because I need to implement
DMA support.

Could you please clearly define and distinguish the following expressions for
me as I have found no such attemp to do this in the many books that I have
found on the subject:

1.      Physical Address Pointer
2.      Virtual Address Pointer
3.      Linear Address Pointer
4.      Flat Address Pointer
5.      16 bit addressing
6.      32 bit addressing
7.      Segmented addressing

If I really looked through all of the book I have, I could probably find a few
more.  Some of them come close to but do not quite explain what actually goes
on under these addressing modes.

I am aware that there was once SEGMENTS and OFFSETS and I DO have a clear
understanding of how they work.  However, now there are SELECTORS and offsets
and the Mastrianni book also describes a method which uses SELCTORS but the
SELECTOR is always equal to ZERO - no reason offered as to why.  I have also
heard the term PAGE addressing being tossed around liberally.  Is a PAGE the
same as a SELECTOR, SEGMENT or niether?

As you probably are aware, the DMA controller register must be loaded with an
address for the source and destination address to it can perform the transfer.
DMA controllers that I have worked with in the past have all used nice, simple
SEGMENT:OFFSET addressing.  Has this changed?  Do I have to perform some sort
of conversion?

The API DosRead/DosWrite request packet passes a Virtual Address pointer the
device driver strategy routine.  What should be done with this in order to
prepare a DMA controller?  Incidentally, the Mastrianni book mentions in
passing that the DMA controller (8237) is a 24-bit controller.  Is this yet
another mode of addressing or is it just another word for something else?

If you could start by explaining the above addressing mode terms to me or
pointing me to some literature that does so clearly, I would appreciate it.

If you have any experience using DMA with an OS/2 device driver, I would
appreciate any help you could give me with that as well.

ANSWER:
1) Physical Address
   These addresses are available in primary storage.

2) Virtual Address
   This uses the segment/selector:offset format of addressing.

3) Linear addressing
   If paging is enabled in 80386 the address generated are called linear
   addresses or flat addresses. These are further translated to physical
   address.

4) Flat address
   In this type of addressing code, stack and data spaces are mapped to same
   linear addresses.

5) 16 bit addressing
   16 bit addressing implies 16 bit registers, operands and address offsets.

6) 32 bit addressing
   32 bit addressing implies 32 bit registers, operands and address offsets.

7) Segmented addressing
This has separate segments for code, data, and stack spaces.  Physical address
can be obtained using segment:offset format in case of 8086 and
selector:offset format in case of 286/386.  Refer "The Design of OS/2" by H.M.
Deitel and M.S.Kogan, Chapter-2.

Page is not the same as segment or selector.  Paging breaks the linear address
space into fixed block called pages (Usually 4k).  If paging is enabled the
resulting linear address specifies a page table, a page frame within the page
table.  and an offset within the page frame.

The DMA controller uses the same simple segment:offset format.  There is no
change in DMA controller addressing.

The virtual address must be converted to physical address using VirtToPhys
DevHlp call.  This memory has to be locked and then programmed to DMA address
registers.  The DMA address channel should be programmed with low byte, high
byte and page register (used in DMA programming).

You can refer to  ad1848.c and dma.c in the following directory:

\ddkx86\mmos2\samples\ad1848 on DevCon DDK 2.0




!OTHER__________________________________**********
July 20, 1995
QUESTION:  (Ref: HY2)
I need your help with installing Warp from floppies.  Our SCSI ADD driver
is'nt included on the OS/2 diskettes so how do I go about installing Warp?  I
have been successful at installing Warp from CD-ROM by copying the ADD driver
to Disk 1 and modifying the config.sys.


ANSWER:
Try this:

SAVECONNECT - If this is set, the the installation program will transfer all
3rd party files to the root directory of the install- ation partition that
were added to diskette 1 by the user.  In addition, any statements that were
added by the user to the config.sys file on diskette 1, will get appended to
the final config.sys file.  This is a method of installing and configuring
devices that do NOT ship in the shinkwrap but are used during the installation
process.




!PRINT___________________________________**********
July 20, 1995
QUESTION: (Ref: HY6)
We are writing an OS/2 Virtual Device Driver which has to support an existing
Windows printer driver (which uses a VxD for DOS/Windows).

Please note that we are unable to change the Windows printer driver in any way
and that we have to try to support the way it currently works.

We have succeeded in implementing most of the APIs which are required to
support the Windows driver, but we are having problems with the support
required for their spooling functions.  These require that we hook interrupt
21h and when the function is 3C, 3D, 3E (Create, Open, Close) with a specific
string, then we must modify the standard behaviour.

We have hooked interrupt 21h by using VDHSetVPMIntVector (along with
VDHAllocHook, VDHArmBPHook) and we use VDHGetVPMIntVector to save the original
int 21h handler so that we can chain to it when we need to.

Using the kernel debugger, I have established that I can only see one call to
the int 21h handler (and that is for function 64H).

My guess is that something else in the OS/2 kernel may be getting the int 21h
before I can process it in my VDD.

Can you tell me what might be happening here, and can you suggest ways in
which I could get the behaviour that I need ?

ANSWER:
It might be possible that the hooked int 21h handler is not being called.  The
VDH function VDMSetVPMIntVector is used only for DOS Protect Mode Interface
(DPMI) support.  Instead you can use VDHInstallIntHook for setting a handler
for V86 interrupts.  The VDD's interrupt handler gets the control first and
the user installed handlers subsequently.

Ref :  details of VDHInstallIntHook devhelp function in VDD ref.  You could
also refer to the following source code for the usage of VDHInstallIntHook
function - ddkx86\src\vdev\vlpt\vlptuser.c ddkx86\src\vdev\vcom\vcom.asm

FOLLOWUP QUESTION:
I have now tried what you suggested, but I am still not seeing any Int21's in
either the Protect Mode hook or in the V86 mode hook.

I understand that it is legitimate for a Windows program to use Dos3Call to
raise INT 21's.  Under "normal" Windows this is exported from KRNL286.exe and
KRNL386.exe and we believe that this would come through to a Windows VxD as an
INT 21.

1) Is it possible that the implementation of DOS3CALL for WIN-OS/2 would route
these calls through to something like the OS/2 kernel, which would mean that
we could not intercept these calls ?

FOLLOWUP ANSWER:
1. You could try the following :-

Use the code in Devcon Vol 7 which describes the means for communication
between OS/2 applications and Windows using VDD's.  In this code you could
send a Windows appl request to the VDD ( Via addr got by int 2fh functions) to
hook the Int 21 interrupt.  The processing routine registered via
VDHRegisterAPI call by the VDD gets control and this routine can be modified
as follows :-

Use VDHQuerySysValue to get the HVDM for the Windows session and then Issue
VDHInstallIntHook in this routine to trap int 21 calls and do no other
modifications to the original code.

2. Your Int21Handler should clear the carry flag to call other handlers in the
chain.

3. Use Kernel debugger to set a break point at your hook handler.  The pcrf
(client register frame) can be used to view the int 21h parameters

Using VDHInstallIntHook Devhlp in the routine handling VDM_CREATE set via
VDHInstallUserHook at VDD Init does not call the handler but using
VDHInstallIntHook with VDM_BEGIN_VPM_TASK as the event for VDHInstallUserHook
calls the handler This would be useful if you are running Windows which uses
DPMI and hence runs a protected task.




!STORAGE________________________________**********
July 20, 1995
QUESTION:  (Ref: HZ1)
I am not able to access the PCI BIOS from my OS/2 Token ring driver.  I have
been trying to use the OEMHLP interface functions ( in this case OEMHLP
Category 80 and function 0Bh for PCI BIOS calls ) and have not been
successful.

I am passing the category number, function number and also the addresses to
the Data_packet and Parameter_packets to the DosDevIOCtl API call, but it
appears that the category or function number that I am passing is not valid
and that the OEMHLP driver returns a status " DONE" to the kernel without
performing any operation.  The same also happens when a DosDevIOCtl2 call is
made.

The contents of the data_Packet structure remain untouched when returned
from the Dosdevioctl call.

a) I upgraded all the library files like doscalls.lib etc to the latest ones
    that came with OS/2 WARP (in the OS/2 developer Connection Apr '95
    CDROM)

b) Ours is a 16bit network driver and thus I was making a 16bit DosDevIOCtl
    call as also a 16bit DosDevIOCtl2 call

c) I stepped through the kernel code via the kernel debugger and found that I
   was traversing functions like " AllocReqPacket", "sw_devIOCtl", "
   DHVerifyAccess", "ProbeBuffer" but eventually lost track and ended up in
   the " SCBReturn" function.


Q1.  This process of calling DosDevIOCtl seems pretty straight forward and yet
       it doesn't work as it should.  Any ideas on how to proceed?

A1.  The PCI bios return code has not been filled in the data packet when
     errors occur.  This is a bug with OEMHLP$.  Defect #96887, for this
     problem, was opened on 09/05/94 and it is sill open at this time.

====================================================================
Q2.  I would also like to know whether PCI support exits in both Os/2 2.x and
     OS/2 WARP.

A2.  PCI support is available on OS/2 2.11 only through a CSD, please contact
     your local IBM representative or the OS/2 Supportline and ask for the fix
     which is APAR PJ14230.  PCI Support was not included with OS/2 until OS/2
     Warp.  APAR PJ14230 is an updated OS2LDR for OS/2 2.11.




!OTHER__________________________________**********
July 25, 1995
QUESTION:  (Ref: HZ5)
Our design requires the DD's Interrupt Mode ISR routines to communicate with
its Kernel mode read routines.  We plan to use the DevHlp "Character Queue
Management" routines (QueueFlush, QueueInit, QueueRead, and QueueWrite) to
implement a communcation mechanism.

Q1.  Are the QueueRead and QueueWrite operations atomic?  In other words, do
the routines that use these operations in Kernel mode have to explicity
disable interrupts before invoking the queue management functions or has queue
integrity already been built into the queue management func- tions?

A1.  The routines using these operations (QueueRead & QueueWrite) in Kernel
mode have to explicitly disable interrupts before invoking the queue
management functions.  The state of the interrupt flag is preserved during
devhlp except the functions Yield & TCYield.

Refer to the Physical Device Driver Reference, Section "State of Interrupt
flag" and Section "Remarks - PushReq Packet"

====================================================================
Q2.  Also, we were told at the PDD Workshop that instead of utilizing the
DevHlp "Request Queue Management" routines, most systems would probably be
best served to implement their own communication mechanisms.  Does this same
advice apply to the "Character Queue Management" routines, and if so, why?

A2.  Yes, the same advice applies to the "Character Queue Management"
routines.  The own character buffer management can be tailored to the
requirements of its buffer structure.  The devhelp services manage a simple
circular buffer.

Refer to the PDD Reference, Section on "Character Queue Management".  You can
also refer to the source code in the following directories of DevCon Vol.
2.0:

       \ddkx86\src\dev\mouse
       \ddkx86\src\dev\touchdd\didd

implementing their own character Queue Management.




!NETWORK !OTHER__________________________**********
July 25, 1995
QUESTION:  (Ref: I07)
We are developing device drivers for PCI network adapters under OS/2.

Q1.  Could you tell us how to get PCI slot information in the device drivers?

A1.  Refer to the PDD Ref. Ch.- Generic IOCtls.  You could use the following
     IOCtl:

      Category : IOCTL_OEMHLP (80h)
      Function  : OEMHLP_PCI (0bh)
      SubFunction : Find PCI Device (01h)

      The Bus Number returns the bus location of a PCI Device.

================================================================
Q2.  What kind of system calls should we make?

A2.  The OEMHLP could be accessed either through DosOpen (Ring 3) or through
the IDC Entry Point (Ring 0).  Use DosOpen with Driver name =OEMHLP$ to get a
handle for use with DosDevIOCtl calls.  This PCI Support is available on Warp.
There is an OEMHLP package on the DUDE BBS which has sample code on accessing
the PCI BIOS functions from Ring 0. The filename is OEMHLP.ZIP and is located
in the MAIN file area.  There is also another file named OEMBASE.INF which
should be helpful to you.




!STORAGE________________________________**********
July 28, 1995
QUESTION: (Ref: HY9)
I have seen references to device-class drivers in the manuals.  A search of
all the Q&A's leads me to believe that device-class driver support is limited
to SCSI devices and OS2SCSI.DMD.  Is this true?

I need to write a driver that sits between the Kernel/FS and OS2DASD.DMD so
that I can filter Request Packets.  Is there documentation on how to write a
device-class driver that works with OS2DASD.DMD??

ANSWER:
The OS/2 DASD Device Manger,OS/2 SCSI Device Manager and the OS/2 ASPI Device
Manager Source Codes are available on the DDK.  Filter drivers source codes
are also available on the DDK.  We do not have any sources for the driver
existing between the IFS & DMD.

In the present scenario, the DMDs are equivalent to the Device Class Drivers.
The Device Class Drivers were able to process the request packets received
from the Kerenel.This functionality can now be achieved through OS2DASD.DMD,
OS2SCSI.DMD & OS2ASPI.DMD.  You could have your filter between the DMD & the
ADD.  Alternatively you could have your own DMD.

The OS2SCSI.DMD does have the device-class driver support.  OPTICAL.SYS is an
example of an IBM Device Class Driver but the source is not available on the
DDK.




!NETWORK________________________________**********
July 28, 1995
QUESTION: (Ref: I05)
Is there a convention for naming device driver files (i.e.  .OS2, .SYS).  I'm
assuming that NDIS device drivers should have an extension of .OS2.


ANSWER:
Device driver for OS/2 NDIS 2.0.1 will normally have an extension of ".OS2".
The network information file must have an extension of ".NIF".  Occasionally,
a driver will have a supplemental file that is different:  such as ".SYS" or
".BIN" or ".EXE" for such things as a ring 3 run-time library or a microcode
file to be loaded by the primary driver onto the adapter card.  These things
are very rare.




!OTHER !NETWORK !PCMCIA _________________**********
July 28, 1995
QUESTION: (Ref: I08)
I have a LAN Adapter card that, once configured, needs to be set into I/O
mode.  My understanding is that after issuing a REQUEST_WINDOW,REQUEST_IO and
REQUEST CONFIGURATION call that the adapter card gets placed into Memory
Mapped mode automatically.  What Card Services call do I use to place the
adapter card in I/O mode?

We are developing a PCMCIA LAN Adapter card for Wireless Data Transmission.The
COR register on the card at adapter memory location 0x800 needs to have a
value of 41h in order to put the card in I/O mode and select level interrupts.
How do I access the adapter memory at offset 0x800 in the device driver in
order to set up the card.

ANSWER:
The client driver is responsible for any memory locations on the card that
need to be written to.  When request configuration is called CS will set bits
to tell socket servies to put into io mode, but any specific stuff must be
done by the client driver.  As far as getting to 800h past the shared memory
location you need to do the following

1) during init allocate a GDT selector
2) get physical address d2000 or whatever from os (devhelp call)
3) do phys to gdt devhelp to relate gdt to physical memory.  There are
   numerous examples of this in the ddk.




!MULTIMEDIA______________________________**********
July 28, 1995
QUESTION: (Ref: I35)
When playback an audio stream, the last second is truncated.  Our audio card
have enough memory to memorize one second of sound.  when the driver receive
the last buffer, it send it to the card, and give it back to the stream
handler using SHD_REPORT_INT(SHD_WRITE_COMPLETE).  But, at this point, the
data(from the last buffer) are on the card, but not played.  At this point,
the stream handler send a DDCMD_CONTROL(STOP_STREAM).  The driver stop the
stream, and the last second of sound(still in the card memory) is never
played.

First Solution Considered:
--------------------------
The driver can wait the end of the playback, before giving back the last
buffer to the stream handler.  problem:the driver cannot recognize the last
buffer of the stream.

Second Solution Considered:
--------------------------
The driver can wait next buffer, before giving previous one back to the stream
handler.  problem:this cannot work with less than 3 buffers.

Third Solution Considered:
--------------------------
When the driver receive STOP_STREAM, it can wait the end of playback from the
audio card.  problem:the driver must wait 1 second, this is too long.  Other
applications needs CPU time.


Can you explain me how the driver should manage such a case ?

ANSWER:
You should only return buffers when you have finished playing them.  You
should examine the driver source available in the DDK (PAS16 and Business
Audio) for additional information.

Solution #2 should work since you would always have at least two buffers in
the driver.

Alternatively you could have a one second time handler for blocking and
unblocking the process, releasing the CPU for other applications.  You could
refer to DevHelp functions ProcBlock, ProcRun, TickCount in the PDD Reference.




!STORAGE________________________________**********
July 31, 1995
QUESTION:  (Ref: I19)
My Filter driver gets it's IORB calls at Task time unless I have several
processes cesses accessing the same filtered drive at once, then my iorb
handler gets called at interrupt time.

Since I want to do my own direct ADD call at interrupt time, I am not sure how
to send my own IORB down to the ADD and get back in the same context, since I
can't block!

I tried a while loop with nops and cli/sti, it worked until I got an interrupt
time IORB, then I never got out of the loop (loop checked for status done).

What is the appropriate way send an IORB to an ADD and get back at interrupt
time?  I must be able to issue my own IORBs.


ANSWER:
If the context is not critical, you can use context hook along with
NotifyAddress in the IORB structure.  Please reference:
\ddkx86\src\dev\dasd\cdrom\atapi.  The ATAPIADDEntry() function in atapiorb.c
calls the SuspendOtherAdd() function in atapigen.c in case of interrupt IORB
which uses a flag to check whether the IORB is in use.  You could use this
Flag Implementation Technique.



