This is file: 06_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)
==============================================================================

!OTHER !VIDEO___________________________**********
June 27, 1995
QUESTION: (Ref: HR0)
I installed the DDK version 2 (APR '95) and I ran the command file COPYC60.CMD
in the DDKX86\SETUP directory.  I tried to build the SVGA utility in the
DDKX86\SRC\SVDH\SVGAUTIL directory.  The compiling (version 6.0) and assembly
(version 5.10a) of the modules went ok but I keep getting link errors.  I
suspect that I am linking with the wrong library.

The errors include many L:2029's (unresolved reference) (e.g.  _int86 and
_int86x) When I ran the COPYC60 command file, I sent the results to a file.
(omiitted)

1. By looking at the output and the command file, I can see that in my
C:\C600\LIB directory clibce.lib gets copied twice to the C:\DDKX86\LIB
directory as CLIBCER.LIB and as CLIBCEP.LIB.  Is this correct?

2. I had no CLIBCER.LIB in the C600 directory.  Can you tell me what library
in C:\C600 I need to build SVGA.EXE?  I tried the C:\C700 libraries and they
did not work.


ANSWER:
1. When copyc60.cmd is executed two files by the names of CLIBCEP.LIB and
CLIBCER.LIB gets copied.  CLIBCEP.LIB is the library for the compact memory
model (the first letter 'C' is for compact model) in protected mode (the last
letter 'P' represents protected).

   CLIBCER.LIB is the compact model library for real mode.

2. In order to build SVGA.EXE, you need CLIBCER.lib.  Refer to the MAKEFILE in
ddkx86\src\svdh\svgautil directory.

FOLLOW-UP:
The problem was that the file that I had in c600\lib directory was called
clibce.lib (because when I previously installed C600 I selected default names
for OS2 libraries - so clibce.lib was equivalent to clibcep.lib) clibce.lib
got copied to ddkx86 as clibcer.lib and also as clibcer.lib.

When I tried to link with this library to build svga, it was the protected
mode library and not the real mode library.  I rebuilt the libraries using the
c6 disks aand reran the command file and the built went ok.  Another thing I
found is that when I ran the build for the virtual video, I got an error
message that vv8514.inc was not found.  I copied the file down from
ddkx86\dbcsdd\src_dbcs\vdev and the build completed.




!OTHER__________________________________**********
June 27, 1995
QUESTION: (Ref. HQ8)
I was tracing through my init code with the kernel debugger with interrupts
off.  While tracing a MOV instruction, my device drivers' timer isr
interrupted me.  My concern is that I was counting on the CLI instruction
(this is a single processor) to protect data structures between OS
strategy/hardware interrupt/timer contexts.  What is happening?


ANSWER:
The kernel debugger will enable the interrupts to get the control.  This is
what is happening in your case.

Also, OS/2 does not permit interrupts to be disabled for more than 400 micro
seconds.  This is for performance reasons.Refer to The Design of OS/2 - Deitel
& Kogan, Ch. - Multitasking, Sec. - Scheduling.




!OTHER__________________________________**********
June 27, 1995
QUESTION: (Ref. HQ3)
To avoid a performance problem with a Novell network, I try to call
DevHlp_Yield when the PDD performs a too long operation.  This call crashes
the system.  (screen black whith cpu registers)

               MOV DL,DevHlp_Yield
               CALL [Device_Help]

1. Are there any particular rules while calling yield?

2. Am I able to call Yield when I want (from a 16bits Physical Device Driver)?


ANSWER:
1. Please make sure that you are calling DevHlp_Yield in the KERNEL context
only.  Please make sure that the pointer to device helper routines is
"Device_Help".

2. The PDD should check the "Yield" flag once every 3 milliseconds for
performance reasons.  If the flag is set, PDD should call DevHlp_Yield.  The
address of the "Yield" flag can be obtained by issuing DevHlp_GetDOSVar call.
DevHlp_Yield switches context only if an equal/higher priority thread is
scheduled to run.  Device driver should not assume that the state of the
interrupt flag will be preserved across a call to DevHlp_Yield.

Let us know what exactly is the error message.  Do you get a Trap ?  If so let
us know the details of the message displayed (when you select Display Register
Information)

FOLLOWUP QUESTION:
The yield error is not a trap.  I receive "Internal Error at ...".

I think this occurs because yield calls the application, and the application
calls the driver again (reentrancy).  So it's my problem to accept reentrancy
(Yes/no?)

I try to read the yield flag, using GetDOSVar.  Perhaps I read it in a wrong
way.

I read in documentation:

    YieldFlag is a BYTE
    You should call Yield() if YieldFlag is SET.

1. What are the values for the Yield flag, only 0 or 1?

FOLLOWUP ANSWER:
Yes, in case of multithreded application and high priority threads in appls,
you may have to take care of reentrancy problem with in your device driver.

You cannot make any assumption on the value of YieldFlag.  The values for the
YieldFlag could be zero or Non-Zero.  Refer to:
\ddkx86\src\dev\printer\prtcommn.asm for YieldFlag being tested for non-zero
value.




!STORAGE________________________________**********
June 27, 1995
QUESTION: (Ref: HP9)
Q1. I am trying to use the OEMHLP device to access the PCI Bios commands.  It
    seems that there may be bugs in OEMHLP's implementation.  For example, if
    you send a PCI_FIND_CLASS_CODE subfunction with a class code that is not
    present on a particular system, OEMHLP returns 0xFF0C as a DosDevIOCtl
    return code.  Instead, it should have returned success but set the return
    code in the pci data buffer to a 0x86.

    The same behavior occurs for other situations such as sending a class code
    that is on your system, but with an index > 0. This also should return an
    0x86, Device Not Found, but instead OEMHLP returns a DosDevIOCtl error,
    0xFF0C.

    I also tried a PCI_READ_CONFIG with a bogus DevFunc, expecting to get the
    DosDevIOCtl error or an error in the pci return code.  In this case, OEMHLP
    returned DosDevIOCtl success and also returned success in the pci data
    buffer return code!

    All of the code described above is written in C and compiled with the CSet
    compiler.  I have done some preliminary work in a device driver using the
    example given in oemhlp.pci on the DUDE BBS but haven't gone as far as in
    the application example.

    I need confirmation of the suspected bugs described above regarding
    accessing the pci bios through OEMHLP from an application.  If there are no
    bugs, I need to see some sample code to see what I'm doing wrong.

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 need complete documentation of the IDC interface to OEMHLP especially
    regarding error returns, etc.  The information in oemhlp.pci is helpful but
    doesn't include all the details.

A2. We do not have any additional documentation besides what is contained in
    the DDK.




!MULTIMEDIA_____________________________**********
June 27, 1995
QUESTION: (Ref. GF0)
I found an error in the Fullscreen Windows support of Warp (I think so).

Since the Warp Version of OS/2 and our new Windows Driver we could do this,
because after starting Windows we fall back to OS/2 (or DOS Fullscreen) with
the error message "Cannot load sound.drv" .

This is curious because Windows wants to load the sound driver 'mmsound.drv'


ANSWER:
There has been an APAR opened on this problem.  The APAR# is PJ18383 and one
problem record associated with this is 8555X,081.  You can followup with OS/2
Support at 1-800-992-4777.




!VIDEO__________________________________**********
June 21, 1995
QUESTION: (Ref: HQ9)
Now that I am actually making progress with the Windows driver port (stage 1,
getting our existing Windows driver to work as a full screen WINOS2 driver, in
progress, stage 2, adding seamless Windows hooks, later) I have come up
against a potentially serious problem which looks like a synchronisation issue
with OS/2.  When switching out of a full screen WINOS2 session, my Windows
driver must carry out some important housekeeping on the adapter to allow safe
switching back into the foreground later.  I am attempting to do this during
int 2F/4001 processing but have been very worried to discover that this call
is only made AFTER PM has been given control and has redrawn its screen
(during which process, the information I need to save from the adapter has
been overwritten).  Could someone please let me know how I ensure that
switches from WINOS2 to PM are correctly synchronised (Windows getting told
that a screen switch is about to happen before PM grabs the hardware).  The
problem may also exist in the opposite direction, PM to an existing WINOS2
session, but I have yet to get this to work as a result of the first problem


ANSWER:
To ensure proper switching from WINOS2 to PM, windows driver must use video
FSRamSemaphore.  Please check that you have implemented the video
FSRamSemaphore to coordinate hardware access.  This semaphore can be obtained,
the necessary register(s) set and used and the semaphore released.

Ref: Display Driver Reference, Chapter on "Seamless Windows Support", section
     on implementation of semaphore processing.  You could also refer to
     WINOS2 sources in IBM OS/2 2.1 DDK additional drivers - WINOS2 diskette.




!VIDEO__________________________________**********
June 21, 1995
QUESTION: (Ref. HP8)
I've been reading the Display driver reference (hardcopy) section on
Installing and Configuring Display Device Drivers.  I'm still not clear on the
purpose/effect of the .DSC file's keyword string that identifies "whether the
display drivers can handle a standard type of display driver".  Can you
explain in more detail:

1.   a) why a driver writer might want to use this field (what advantages?)?
2.   b) under what circumstances a selection will work or fail (might DSPINSTL
        determine that my device, which I identified as a kind of SVGA, really
        should not be associated with a standard?
3.   c) what, if any, relation there may be to a .PMI file (in the case of
        SVGA)?
4.   d) where I can find the definition of the parameters associated with the
        selection of a standard device?

Regarding d), I've looked at Warp's .DSC files for the S3 864 and WD 90C33.
Both identify the adapter as type "SVGA".  But whereas Display.inf says that
the standard type key string is followed by:

     "1" /* Required parameter; must be set to 1 */
     "0" /* Required parameter; must be set to 0 */

I see the S8 864 .DSC follows the SVGA type key with:

     * #additional parameters specific to VGA
     "2"
     * Additional parameter (Chipset manufacturer = 8 for S3)
     "8"
     * Additional parameter (Chipsets supported by driver)
     "4 5"
and WD uses a similar scheme.

Apparently, I don't have all the information I need on the standard key type
parameters.  I've looked at the Video PMI section on Video Configuration and
Installation, but there's not much information there yet (In fact, the
hardcopy documentation says, literally:

5.   "Information can be obtained on the current adapter and monitor
      configuration. [where ??]"


ANSWER:
The section on Installing and Configuring Display Device Drivers Chapter 10
in the Display Device Driver Reference. There are new features in DSPINSTL
that are not documented in this chapter.  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 screen01.sys driver.
If 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
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 somewhere I don't know where or pull it off
the build tree in h\svgadefs.h.  This file contains information about
manufacturing code defines as well as chipsets.


I forgot to mention section d. in response to your question.  The information
in Chapter 10 saying that addoitional 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.


5. The documentation in the Display Driver Ref. says - The current video
configuration is stored in the VIDEO.CFG configuration file.  The monitor
database is stored in MONITOR.DIF file.




!PRINT__________________________________**********
June 21, 1995
QUESTION: (Ref: HP7)
We are writing a VDD which will mimic an existing Windows VxD to support a
Windows Printer driver under OS/2.

Part of the way in which the original VxD works is to read an entry from the
Windows system.ini file to decide which parallel port the printer is connected
to.

1. We need to be able to read the SYSTEM.INI file for WINOS/2 from our VDD.  I
am not aware that the Windows API calls to read the SYSTEM.INI file are
available to an OS/2 program - is this correct?

2. Alternatively, we could read the SYSTEM.INI file directly if we could find
out which was the Windows directory.  Again, my guess is that the functions
GetWindowsDir and GetWindowsDirectory would not be available to OS/2 programs.
Is this correct?

3. Is there any example OS/2 code available which would show me how to read
the SYSTEM.INI file from a VDD, or can you suggest how we might try to do
this?


ANSWER:
1) Windows API calls are not available to a VDD.

2) The windows directory is \os2\mdos\winos2 in OS/2.  GetWindowsDir and
GetWindowsDirectory calls are not available.

3) You could use VDHOpen,VDHRead,VDHClose calls to open, read, close the
SYSTEM.INI file and look for the needed info.




!VIDEO__________________________________**********
June 21, 1995
QUESTION: (Ref: HP5)
The Display.inf book does not list ":TITLE" or ":DEL_CONFIG_LINE" as valid
DSPINSTL commands.  Can I continue to use these (particularly the
DEL_CONFIG_LINE command) under Warp, or are these old commands whose support
may be dropped in future releases?


ANSWER:
The :TITLE & :DEL_CONFIG_LINE are valid DSPINSTL commands and will be
supported in future releases.  You could therefore continue to use these
commands.  It will be documented in the Display Driver Ref.,shortly.




!OTHER__________________________________**********
June 21, 1995
QUESTION: (Ref: HO3)
When I use the 'AllocReqPacket' DevHelp call, what kind of packet is
allocated?  I assume at least large enough for the Packet header stuff to
include linkage, but how much else?  I'm interested in casting it as various
types so would like to know what the limits are.


ANSWER:
1) AllocReqPacket returns a pointer to a maximum sized request packet.  The
common packet header size is 13 bytes and the Maximum command specific Packet
Data length is 18 bytes (Refer to ddkx86\inc\devsym.inc)

2) The request packet header contains a DWORD field for queue linkage.

3) The returned address can be casted to various types.

Ref : PDD ref, Ch - Physical Device Driver Strategy Commands
      You could also refer to "Writing OS/2 2.1 Device Drivers in C", Steve J.
      Mastrianni, Appendix - C, section on "Standard OS/2 device driver include
      file" for the request packet structures. This book is part of DevCon DDK
      V1.0, 2.0 (SMBOOK.INF)




!OTHER__________________________________**********
June 21, 1995
QUESTION: (Ref: HN7)
1. Is there any way that a character driver can distinguish request packets
between multiple applications programs all of which have OPEN'ed the device?

For example:  AP#1 Opens device 'GEORGE'.  Then AP#2 Opens device 'GEORGE'.
Now AP#1 starts making IO requests like READS, or WRITES, etc.  AP#2 then gets
into the act and starts doing the same kind of thing.

2. Is there any way for the drive to be able to tell from the contents of the
Reqeust Packet which of the OPEN's this request is associated with?  At the AP
level, of course, the user has the "file handle" to distinguish the streams.
Any such thing available for the humble and well-behaved Device Driver?


ANSWER:
1. You can distinguish request packet between multiple applications using
"System File Number-SFN".The SFN is a unique number associated with an Open
request.  With a successful DosOpen the SFN is assigned by the kernel and this
can be verified in the Open/Close request packet.  When Read/Write, IOCtl is
invoked with relevant device handle, the request packet is generated with the
corresponding SFN as assigned by the kernel.  Ref:  PDD Online Reference.  CH.
Physical Device DriverStrategy Commands.

2. Refer answer 1.

Alternatively you could also use the DevHlp_GetDOSVar - the LocalInfoSeg has a
ProcessID Field which could distinguish between the two requests.




!PRINT__________________________________**********
June 21, 1995
QUESTION: (Ref: HN4)
I have been developing Fax Gateway client for OS/2.  It's like a printer
driver.

So I'd like to know how my driver forces output to a file with OD_DIRECT or
OD_QUEUE.

Somtimes I have to set the file pointer during write document.


ANSWER:
Your driver can force the data to goto a file by forcibly setting the 'ulType'
parameter as OD_QUEUED in the function OS2_PM_DRV_ENABLE :  subfunction 02h -
FillPhysicalDeviceBlock.

Ref : Presentation driver reference, Ch - 10, section on OS2_PM_DRV_ENABLE
      You can refer to Ch - 6 of the same book for the concept of output
      strategy




!OTHER__________________________________**********
June 21, 1995
QUESTION: (Ref: HN3)
Compile errors with Borland C on Resource Manager supplied H files.

Using:

  RMBASE.H V1.01
  RMCALLS.H V1.01
  RMIOCTL.H V1.01

as supplied by IBM, I get compile errors that indicates a comma is missing on
each and every typdef statement.

What we have tracked down is that evidentally Borland C 3.1 doesn't like the
FAR * and NEAR * references in the typedefs ...  as in:

    typedef ULONG   RMHANDLE, FAR *PRMHANDLE, NEAR *NPRMHANDLE;

There are many typedef's like this and I don't want to kludge up your files,
plus it would turn into a maintenance nightmare for updates.

My questions are:

1. What compiler are you using?

2. Has anyone else run into this problem?

3. Are there other H files that I should be using that eliminates this
problem?


ANSWER:
1. RMHELP.C ,RMCALLS.H,RMIOCTL.H & RMBASE.H files require MSC 6.0 compiler.
The Microsoft C v6.0 is a 16 bit compiler.  Borland C being a 32 bit compiler
will indeed dislike the NEAR/FAR Keywords.

2. The incompatibility is because you are using Borland C instead of Microsoft
C 6.0. You could probably port the Header Files to Borland C before using it in
your driver.

3. No additional header files required.




!NETWORK________________________________**********
June 21, 1995
QUESTION: (Ref: HM3)
We are trying to determine what changes will be needed to our OS/2 NDIS device
driver for our network adapter to support OS/2 SMP.  I have heard that there
is a white paper outlining what needs to change to support OS/2 SMP.

Do you know of such a paper, or could you recommend another method for finding
out what needs to be modified?

If we use spin-locks, are there services provided for this under OS/2, and
does this service exist under OS/2 2.11 (or do we need a separate driver for
OS/2 SMP)?


ANSWER:
As far as changes to NDIS drivers for SMP goes, I found in my testing of Lan
adapters for SMP that many did not need any modifications.  They ran fine
under OS/2 for SMP 2.11.  The most common problems with the drivers that did
not work under SMP were code that attempted to modify the PIC directly, and
code that tried to register stack space or other items directly.  If the
driver always used the DevHlp calls as documented in the SMP.INF file, I
believe all things would work perfectly.  This was one of the main design
points for OS/2 for SMP, that most existing code would run unmodified.  I
believe the spin-lock APIs come as a standard feature in the SMP toolkit.
Again, the SMP.INF (the one I have came from the SMP CD) has a lot of info on
this.




!I/O____________________________________**********
June 21, 1995
QUESTION: (Ref. HM0)
1. Is there an example device driver on the DDK that shows how to do
something similar to our application?

Application:
We have two ISA devices, a five TMS320C40 DSP processing board, and an optical
beam position scanner (dual axis motor controller) board which is based on a
TMS320C31.  The C40 board is processing laser radar data.  Data becomes
available every millisecond from both boards.  We need to be able to process
interrupts so that we can match the data in time sequence from the two boards
and get the data into the PC in real time.  When we poll the cards, OS/2 will
periodically suspend the thread resulting in a loss of data.

2. Do you maintain a list of device driver consultants and if so, can you
provide us with a list of those who are located here in the Washington DC
area?

3. Is this forum accessible via the Internet?  Internet e-mail is much more
accessible to me than a BBS like this one.


ANSWER:
1. The closest thing to your applicaton on the DDK would be -

    \ddkx86\mmos2\samples\ad1848        Audio device driver
    \ddkx86\mmos2\samples\mad16         Audio device driver
    \ddkx86\mmos2\samples\vcaddt        Video Capture device driver

The above mentioned source meets requirement on multimedia device driver and
capturing data in real time.  You can also refer to the documentation on
MMPM/2 Device driver reference.

2. We do not have a list of Device Drivers consultants, however you might want
to try and put a message out on Prodigy.

3. As our SYSOP already explained to you, we are not accessible through
Internet.




!VIDEO__________________________________**********
June 21, 1995
QUESTION: (Ref: HL6)
The "Video Configuration Manager" section of Display.Inf's "Base Video Handler
Display Driver"\"BVHSVGA.DLL"\"Installing Video Configuration Mgr for OS/2"
begins as follows:

     "VIDEOCFG issues a DevQueryDisplayResolutions call to the PM driver
     to obtain a list of resolutions supported by the driver..."

Q1. What is the DevQueryDisplayResolutions call?  Should this read
    "OS2_PM_DRV_QUERYSCREENRESOLUTIONS"?

A1. The DevQueryDisplayResolutions call is used to query the PM driver to
    obtain the list of resolutions supported by the driver.  The prototype of
    this call is defined in ddkx86\h\pmgpip.h.  This is a user level call.

    OS2_PM_DRV_QUERYSCREENRESOLUTIONS is the entry point, it should be exported
    by the display driver that supports multiple display resolutions.  This
    function is called by DevQueryDisplayResolutons.
==============================================================================

Q2. I am trying to relate the information in this section to the S3 driver
    section on "Multiple Resolution Support".  My belief is that the Settings
    notebook page (VideoCfg?)  calls OS2_PM_DRV_QUERYSCREENRESOLUTIONS.  The
    display driver, at the routine that processes this call, should return the
    screen resolution table of ALL resolutions/bpps that this driver can do
    REGARDLESS of the memory equipped on this particular adapter.  The
    "filtering" of which resolutions are actually obtainable for the user's
    configuration is done via the use of the DSP_RESOLUTION_OBTAINABLE flag.
    Is this a correct assumption?

A2. Your assumption is correct.
==============================================================================

Q3. Thank you for the info, the referral to DDKx86\h\pmgpip.h was useful.
    There does not appear to be a corresponding file in \inc, which (as our
    driver is in assembly) is where I usually hunt for definitions.  This may
    be an oversight in the DDK.

A3. We plan to include the corresponding file for DDKx86\h\pmgpip.h in \inc in
    the next version of the DDK.  Please run the following and this will create
    the file you want:

       "H2INC -t -c pmgpip.h -o pmgpip.inc"




!STORAGE________________________________**********
June 21, 1995
QUESTION: (Ref: HJ4)
Q1. Do you know of anyone who would have an updated OPTICAL.SYS which supports
    1.3 - 2.0 GB MO SCSI devices for OS/2?

A1. There is an OS/2 Hardware Compatibility List available in the Main file
    area on the DUDE.  The name of the file is PCMTABLE.ZIP.  Please download
    this file for information on OS/2 Device Drivers.  There is information
    about optical drivers in the section entitled "OS/2 Miscellaneous Storage
    Support".
==============================================================================

Q2. I'm looking for the source code for optical.sys so that I can write
    compatiblity in for the Hitachi OU152 2.0 GB MO Drive.  Can you help me?

A2. Regarding OPTICAL.SYS, we cannot provide any source code but my contacts
    tell me that if you need a function added to the current code, you may
    submit your suggestions to us and they will review your requests.




!VIDEO__________________________________**********
June 21, 1995
QUESTION: (Ref: HF5)
Q1. We are planning to use the PMI file to set video modes.  In order to do
    that, we need to set "ICD2061A" Graphics Clock Generator within the PMI
    file.  Are there any limitations in doing this?

A1. Refer to ddkx86\src\ibmgpmi\ipmimain.c for setting the ICD2061A.  As far as
    we know, there are no limitations.
==============================================================================

Q2. Is there a sample PMI file available?

A2. Run SVGA on Diamond Viper to get a sample PMI file.
==============================================================================

Q3. I am trying to generate a PMI file which INCLUDES the code to set ICD2061A
    and avoid using "IBMGPMI.DLL".  I have sample "VIPER.PMI & VIPERNEW.PMI"
    files which had [SetMonitorTimings], and [ProgramClock] sections.  Looking
    at "SVDH\SVGAUTIL" on DevCon DDK Ver.  2 , I don't see how this file can be
    generated.  Would you let me know how you generated this file?  Can we
    stick to the PMI file only and avoid using IBMGPMI?  What is the advan-
    tage of using IBMGPMI?

A3. You can stick to the flat PMI file and have the IDC programming section
    within the flat file.  If you run svga.exe on top of Diamond Viper VLB, it
    should spit out a file that has memory mapped register programming and
    invocation of the clock function.  The file will look considerably
    different than the sample viper.pmi that you have, since the sample
    viper.pmi was used to demonstrate what kind of stuff can be done.  SVGA.EXE
    can format all of the new syntax, however, setting up the adapter
    structures (using the regdata lists) is somewhat awkward.  You can look at
    svgadiam.c which features how we used the Diamond's viper.ini file as a
    source of info on how to program the board (you should come up with
    alternative methods to cover your new adapters).  The actual ProgramClock
    section for ICD is defined in chipdata.c as REGDATA ICDesign1 and
    WriteClockFunction, in svga.c, formats the section.  The call to the
    function within the setmode is done via the WriteClockModeSection function
    (r0 gets set with the correct data).

    Notice that we commented out both WriteClockFunction and WriteClockMode-
    Section and instead the REGDATA for WeitekSetMode (see chipdata.c) has a
    PMICMD_CALL command which formats "call pfnPMISetMonitorTimings" which is
    defined in ibmgpmi.  We have done that because there is a theoretical
    limitation when programming timing sensitive chips (such as IDC) from a
    flat PMI file.  The PMI file is interpreted into a command list.  The
    command list execution carries a certain overhead in comparison with
    executing compiled code.  We have found that in most cases, VGA registers
    were programmed more successfully out of the command list (PMI) than
    compiled code, since most of them required a delay between successive outs.
    In those terms, PMI proved beneficial (most BIOS's will generate delay code
    in order to ensure that IO operation has "settled").  But when it comes to
    clock state changes, some hardware requires that all of relevant registers
    be changed within a minimum time-period.  This can't be ensured with PMI,
    although it theoretically can't be ensured with compiled code either, being
    bound into CPU speed.  The compiled code however will always fare better
    since manufacturers always ensure that their hardware is successfully
    programmed by the BIOS on all of the commericial CPU's.

    The bottom line is, we do all of our ICD programming from the IBMGPMI as to
    minimize the exposure to timing sensitive programming issues.  Whether you
    choose to stick with PMI and find out in practical testing if you are
    exposed to it or not will have to be your decision.

    You most likely have certain variations to your clock programming (and
    refresh configuration) from one adapter manufacturer to another, and
    deciding on how to balance those within the PMI (flat file inclusion, DLL
    inclusion or SVGA.EXE adapter specific modifications) may be another issue
    that will sway you one way or the other, so I suggest that you consider
    those first.

    1) Do you have different clock programming function across adapters?  Even
    if the clock programming is the same, will adapter manufacturers change the
    way the configuration is stored or black-out (or enhance) the refresh
    range?

    2) Do you have different DACs across adapters?

    3) Do you plan to support all the adapters or delegate that to the adapter
    vendors?  Do you plan to ask them to supply their configuration/DAC/clock
    specific portions?  Would your vendors consider making source changes to
    the IBMGPMI.DLL or would they prefer supplying a VENDOR.PMI flat file which
    can be included into the main PMI file?  Or would you ask them to modify
    SVGA.EXE (the most difficult of all options).  The inclusion of the flat
    file works but your basic PMI file has to be written to take care of the
    inclusion and you can't let the vendor come up with a variation to a
    function that originally wasn't going to be included.  Then the vendor
    faces the cost of modifying the svgadata.pmi (or the ibmgpmi.dll) which
    diminishes the appeal of the flat file inclusion.

    4) The MMIO base address has to be formatted correctly (has to match the
    PCI configuration).  SVGA.EXE could issue PCI calls (it doesn't at the
    moment) and change the "Hardware" section.  If you put any memory mapped
    programming into IBMGPMI, the virtual address of your aperture is not
    passed in, so you have to obtain the mapping (which is easy by getting a
    shared mapping for the physical aperture from the "Hardware" section via a
    SCREEN01 ioctl B).  If any of your WinOS2 drivers modify the physical
    aperture addresses, then you also have the complexity of configuring the
    aperture each time the set mode is called (no using the PCI BIOS now, just
    hardware register interface!).

    One clear disadvantage of using the IBMGPMI is that there is a source
    change/ recompilation when running on a PPC platform.  So, you may want to
    limit usage of the imported binary for functions which are very common yet
    hard to format using svga.exe in a flat file format.  If your vendors
    wouldn't appreciate having to make source changes, you want to delegate
    their adapter specific functions to an included sub-PMI file.  We wouldn't
    even try to come up with a tool to format this included file, just edit the
    file straight from scratch.

    We are sorry that we can't tell you which will work best for you.




!STORAGE________________________________**********
June 21, 1995
QUESTION: (Ref: HD8)
We are engaged in designing PCI-IDE Cache controller card which supports ATA
IDE HD drives and ATAPI CD-ROM drives in a single card.  We are now writing a
device driver for this card to run under the OS/2 Warp Version 3.0.  We
confront a problem which is related to the PCI I/O Mapping Address.

Here is a brief description of the problem.  Our PCI I/O Mapping address is
assigned by the motherboard.  Normally, the address is assigned to be "FC00"
but sometime some motherboards will assign us a different address such as
"D800" or "6000".  We use it as our PCI I/O Mapping Address.  When we install
the OS/2 Warp after the first reboot, the OS/2 installation program halts at
the moment when a "OS/2 Setup and Installation" procedure is executing.

We found out our card doesn't work which is caused by the file "7770PRES.EXE"
in the directory of "C:\OS2\DRIVERS".  The "7770PRES.EXE" is a detection
program from Adaptec 7770 EISA adaptor and it will check for I/O address from
"0C00" to "FC00".  When the program checks the I/O adress "FC00" for Adaptec
Device, it will cause our controller to halt.

The above problem happens only at address "FC00" in according to our
knowledge.  If motherboard assigns an address different from "FC00", our
controller card will work fine without any problem.  Can you recommend us some
solution to avoid this problem without changing our device driver?


ANSWER:
If you are using OS/2 WARP then you can use the resource manager to reserve
the address FC00.  You could specify the shared attribute for the address.
For this you need to include the following line in CONFIG.SYS (MUST BE THE
FIRST LINE IN CONFIG.SYS)

BASEDEV=RESERVE.SYS /MEM: FC00, <no. of addresses in hex format> /SHA

Resource Manager docs are available on DUDE BBS (RMBASE).  Also, PDD reference
(online version of DevCon DDK V2.0) has info on the Resource Manager.




!OTHER__________________________________**********
June 21, 1995
QUESTION: (Ref: GO1)
Q1. I have TOOLINFO.INF from the DevCon DDK 1.0 but this is the only
    documentation I can find on LINK386.  By experiment, I have found that it
    is possible to link a PDD with LINK386 and these seem to work.

    I am curious about the exact semantics for some of the keywords available.
    TOOLINFO says that these are useful only for device drivers and then says
    not to worry about them.  This does not work for me since I am writing
    device drivers.

    I assume that a segment marked "PERMANENT" is non-swappable but is
    moveable, while a segment marked "RESIDENT" is neither swappable nor
    moveable.  If I mark a segment as both "PERMANENT" and "RESIDENT," this is
    interpreted by EXEMAP as "CONTIGUOUS."  Am I right about all of this?  Are
    there additional useful keywords?

A1. For a definition of these terms, look in EXE386.H in the toolkit:

      OBJPERM  Object is permanent and swappable
      OBJRESIDENT Object is permanent and resident
      OBJCONTIG  Object is resident and contiguous
               OBJCONTIG=OBJPERM | OBJRESIDENT
      OBJDYNAMIC  Object is permanent and long-lockable
==============================================================================

Q2. This is a specific question about a situation which works properly under MS
    LINK but not under IBM LINK386.  I am using whichever LINK386 version was
    shipped with Devcon DDK 1.0, I believe it is version 2.02.001 Jun 09 1994.

    The problem was encountered in the course of writing a DMD, in connection
    with passing the address of the notification function within the specified
    field on an IORB.  In particular, I have the following declaration in a
    header file which is common to all modules:

    PIORB _loadds FAR post(PIORB);

    The actual function definition is very simple:

    PIORB _loadds FAR
    post(PIORB piorb) {

                USHORT count;

                DevHelp_ProcRun((ULONG)piorb, &count);
                return(piorb);
    }

    The IORB field is then filled in with the following code, which I tried
    both with and without the explicit '&' operator:

    PIORB_ADAPTER_PASSTHRU piorb;

    piorb->iorbh.NotifyAddress = &post;

    This compiles correctly to the following assembly code:

    * 0000bf   26 c7 44 1c 00 00    mov     WORD PTR es:[si+28],OFFSET _post
    * 0000c5   26 c7 44 1e 00 00    mov     WORD PTR es:[si+30],SEG _post

    The address of post() is left as a relocatable item to be handled later by
    the linker.  The entire driver has only one code segment.  When linked by
    either LINK or LINK386, the following appears in the map file:

    0002:0358       _post

    When running the kernel debugger, I find that the code segment for this DMD
    is loaded at selector 05D8, and the post() function actually appears at the
    virtual address 05D8:0358, as expected.  In the case of the NE-format made
    by LINK, the "OFFSET _post" is correctly replaced by 0358 at load time.
    However, in the case of the LX-format made by LINK386, "OFFSET _post" is
    incorrectly replaced by 4300, a difference of 3FA8.  In fact, when the ADD
    executes the callback to 05D8:4300, this address is past the end of my code
    segment and a trap D is generated.

    In the course of further examination, the base linear address of the code
    segment is different when displayed using the "dg" and ".lm" commands in
    the kernel debugger.  The GDT entry for selector 05D8 might show a base
    address of %FE226000, while the MTE for the same selector might show a base
    address of %FE223FA8 -- note the xxxx3FA8 value, exactly the same as the
    difference between the proper offset and the computed offset.  For both the
    fixed data segment (selector 05D0) and the swappable data segment (selector
    05E0), the GDT and MTE base addresses match regardless of which linker is
    used.

    Recognizing the significance of the "000" suffix of the linear address
    shown by the "dg" command, I tried changing the linker definition file for
    LINK386 so that the code segment was set CONTIGUOUS instead of just
    RESIDENT but that only caused ".lm" to show the linear address in the MTE
    as %FE224000, while leaving the GDT address shown by the "dg" command still
    %FE226000.  While the post() function was actually loaded at 05D8:0358 in
    either case, the LX-format version replaced "OFFSET _post" with 4358, an
    error of exactly 4000.

    I am not sure if this is a bug in LINK386 or in the operating system
    LX-format loader but I can't imagine that it is caused by anything I am
    doing wrong.  This problem would likely never be encountered except in
    trying to pass the address of a function to another driver, since calls
    within the driver are handled as near calls not subject to relocation
    fixup.  It seems evident that there is no legitimate situation in which the
    GDT information, which is obviously really valid, and the MTE information,
    which is apparently used to do the loader fixup, would differ.  On the
    other hand, OS2KRNL is itself in LX-format and it is inconceivable to me
    that a problem like this could exist without somehow seriously breaking the
    operating system.  I am very interested to know what has gone wrong and
    where the cause ultimately lies.


A2. We have reproduced, debugged, and created APAR PJ18521 to address this
    problem.  Please contact the OS/2 Supportline at 1-800-992-4777 to
    periodically check the status of the APAR.




!OTHER__________________________________**********
June 21, 1995
QUESTION: (Ref: GB8)
I have a question concerning stack usage in DOS drivers running in an OS/2
VDM.  We use a lot of our DOS device drivers in an OS/2 VDM, some of these
drivers appear to be using too much stack space during their initialization in
certain circumstances.

Example:  The latest version of one driver uses 16 more bytes of stack space
than the previous version.  Immediately after the driver is loaded, a 'Command
Interpreter Bad or Missing' error occurs.  When the driver first gets control,
SP is 0CAh.  The version that works uses up to SP=1Ch, which is 174 bytes of
stack.  The version that does not work uses up to SP=0Ch (190 bytes).

Our drivers use a lot of stack space primarily because they are written in C,
so I think that others could run into the same problem we are having.
Basically, any driver using 180 or more bytes of stack (SP reaches 16h) by
pushing too many times or allocating too much local data during initialization
would cause an error.  The error could be 'Command Interpreter Bad or Missing'
displayed immediately after the driver installs or some nasty error that pops
up in an error message box.  If I remember correctly, the nastiest errors
occurred when SP reached 4 and the driver tried to push something else on the
stack.

While we were using the kernel debugger to investigate the problem, we were
filling the part of the stack segment near zero with some value, such as EDh,
so that we could tell how much stack space we were using.  This would force
an error to happen even if the driver didn't use much stack space.  Though
once I did cause a nasty error that forced me to reboot when I filled in a
different value!

I am looking for the following information:

1) How much stack space is available to a DOS driver during initialization in
   a VDM session?

2) Is the amount of stack space less than what DOS would allow?  Our drivers
   appear to work in DOS.  In DOS, I believe we saw the stack pointer at
   offset 500-and-something in the stack segment instead of very close to
   zero.

3) Is there any way to increase the amount of stack space available to a DOS
   driver in the OS/2 VDM other than having the driver allocate its own stack
   as soon as it enters its Strategy/Interrupt entry point.  We have already
   changed our drivers that use 172 or more bytes of stack space during
   initialization to use their own stack.  We saw problems with any driver
   using 180 bytes or more.  We are currently planning to change the remaining
   drivers in a future release.


ANSWER:
MVDM's DOSKRNL has a structure defined in the file r207\src\dos\dosinc\dem.h
which defines the DOSKRNL state (including the STACK) during DOSKRNL
initialization.  On line 48, is the hard-coded DOSKRNL init code stack "USHORT
v86i_ausStack[128];".  This means that there are 256 bytes in the init stack.
From your comments, I can assume that DOSKRNL init must be using close to 80
bytes when it calls the DOS device driver, leaving less than 180 for the DOS
driver.

I do not recall the exact size of real-DOS' stack when it calls a DOS device
driver, it probably is 500+ bytes free as you indicated.  Changing the dem.h
value of v86i_ausStack from 128 to 400 should give the DOS device drivers 600+
bytes free.  Changing this value will require a new DOSKRNL and a new OS2KRNL.

A DOS device driver should change to use it's own stack.  Every version and
flavor of DOS (MS-DOS, IBM-DOS, DR/Novell-DOS, 7.x, 6.x, 5.x, etc.)  and DOS
emulators (OS/2, NT, Chicago) will have a different size.  DOS device driver
"strategy" workers just save the request header value and return, so they
should not be affected.  A DOS device driver "interrupt" worker must preserve
all registers.  So typically their first statements are to push all the
registers and, on exit, to pop them off.  Beyond the space to save your
registers, I can't guarantee the amount of stack space left free.
Furthermore, no IBM nor MS publication makes any guarantee of the amount of
free space.  Therefore, changing to your own stack eliminates problems no
matter what system you use.  Don't trust the OS if it's not a documented spec.

Nevertheless, this is a valid bug in OS/2 and APAR PJ17456 has be written to
address the matter (fix described above).  Please contact the OS/2 Supportline
at 1-800-992-4777 for a status of this APAR.




!PRINTER________________________________**********
June 16, 1995
QUESTION: (Ref: HP2)
We developed a parallel keypad that has a pass-thru connector for the printer
to attach.  All 25 lines are passed thru except for pin 13 (select status),
and pin 15 (error).  These two pins are used by the keypad for power/scanning.

The DD works fine as is.  The problem is that we cannot print through our
connector.  If I send a print job, nothing prints until I remove the keypad,
and attach the printer directly.  It appears that either the printer driver or
the kernel is using the select line and is seeing the keypad.

My driver is written as a PDD, but I do not take over the IRQ.  I access the
I/O port directly to read/scan the keypad.

This problem does not occur under DOS.


ANSWER:
Pin 13 & Pin 15 (select/error) are Input Pins and originate from the Printer
and are used by the Printer Driver.

The OS/2 parallel port device driver (print01.sys) is loaded before your
Parallel Port device driver).  The parallel port dd provides an IDC enabling
other drivers to request and release exclusive access to the parallel port.
This means that your driver can call the parallel port dd and request
exclusive access to the parallel port hardware.  Once your driver has
exclusive access the parallel port will not touch the hardware until your
driver releases the access.  This is documented in the I/O Device Driver Ref,
parallel port dd chapter, Section on Sharing the Parallel Port with other
Device Drivers (in the DDK).  You could also refer to an article that was
written in the Developer Connection News (Vol 4) which gives a source code
example how to issue the IDC calls.  Your driver must not access the parallel
ports without first gaining access otherwise your parallel port device driver
may not coexist with PRINT01/PRINT02- System Parallel Port Driver.




!OTHER__________________________________**********
June 16, 1995
QUESTION: (Ref: HO7)
Page 202 of the Input/Output Driver Reference manual makes reference to using
a blank space after PCMCIA$.  If I do not want to interface with COM.SYS, then
should I omit the space in the driver name entry (i.e.  "PCMCIA$" versus
"PCMCIA$ ".)  when making the DevHlp_AttachDD call.


ANSWER:
The 'DDName' parameter of DevHelp_AttachDD call specifies the name of the
device driver and MUST be 8 characters long.  Whether you want to interface
with COM.SYS is irrelavant.  So the driver name has to be 'PCMCIA$ '.




!MULTIMEDIA_____________________________**********
June 16, 1995
QUESTION: (Ref: HM1)
I have problems with Spi calls under WARP (SpiInstallProtocol,
SpiStartStream).  With Warp, spiInstallProtocol returns an error 5612!!  The
same call to SpiInstallProtocol under OS/2 2.1 returns no error.(The program
is the same in the two cases).

If I suppress the call to SpiInstallProtocol in my program, I can start a
stream under OS/2 2.1, and my application works without problem.  Under Warp,
I have a GP fault when I call SpiStartStream!!  (Our own PDD doesn't receive
the START).

Why these problems?  Is there a reason?  Is it a problem in the application,
or in SSMDD.SYS or ADSHDD.SYS of WARP, or is it a configuration problem?


ANSWER:
Warp supports install protocol, and based on your code snippet, we don't think
that ADSH being a stream handler makes a difference.

To help isolate the problem remove the following flag:

>spcb.ulBufFlags |= SPCBBUF_FIXEDBUF;    // buffers characteristics

and change it to SPCBBUF_MAXSIZE




!MULTIMEDIA_____________________________**********
June 16, 1995
QUESTION: (Ref: HL4)
The PAS16 (Media Vision's Pro AudioSpectum 16) PDD sample source code in OS/2
DDK contains too many "PAS16 hardware dependent" portion (Even the MIDI FM
contains it).  It's difficult for us to port these codes to our own PDD.

It seems most of the sound chip vendors designed their ASIC with Sound Blaster
compatible and if possible, could you leaglly provide these kinds of the PDD
sample source code (For example OPTi-929, ESS688 ,,,etc) ?


ANSWER:
We are unable to provide other vendor's code.  The only other samples we have
are on the DDKis the AD1848 source.  You can find this in the path
\ddkx86\mmos2\samples\ad1848.




!BASE___________________________________**********
June 16, 1995
QUESTION: (Ref: HL0)
Q1. I would like to allocate a 4K buffer using AllocPhys then, using PhystoVirt
    to obtain a selector to the buffer, run it thru the makep() to get my
    pointer and offset for this buffer at init time.  From an application I
    would like to fill up this buffer first with 4K of data using the
    DosWrite().  Is this feasible or do I have to use AllocGDTSel() to obtain
    the selector, then use PhystoVirt and makep() it?

    Once the buffer is loaded, I would like to load a memory mapped card from
    this buffer using an external interrupt (I will be using IRQ10), 20 bytes
    at a time, so at the arrival of the first interrupt my pointer is pointing
    to the beginning of the above buffer, then load the card, and then I would
    like to add 20 to this pointer and save it.  When the next interrupt
    arrives I would load the card from the 20th element of the buffer and so
    on.  When I reach the end of the buffer, I would like to reset the pointer
    to the beginning again.  How do I save this pointer inside of my driver so
    at the arrival of each interrupt I can examine it for the end of the buffer
    and add 20 to it?  For the clarity reasons, please see the following pseudo
    code:

    if(intrp){
       if(MYBUFFER==end_of_the_ buffer)
          MYBUFFER=begining_of_the_buffer;
       movebytes(MEMMAPCARD,MYBUFFER,20);
       MYBUFFER = MYBUFFER + 20;
    }

    I would like to implement the code inside the body of the if statement, in my
    driver.

A1. You could do the following in your INIT section.

    - AllocPhys
    - AllocGDTSelector
    - PhysToGDTSelector (this will give you access to the memory during all
       contexts)
    - MAKEP() (save the pointer in a global variable. Make sure that data
       segment is fixed in memory by specifying the IOPL attribute for that
       segment)

    In the ISR -

    ISR()
    {
      ULONG Index;
      Index+= 20;
      MyBuf = *(StartBufPointer + (Index % 4096))
      MoveBytes()
    }
==============================================================================

Q2. How do I specify the IOPL attribute?

A2. Refer to ddkx86\src\dev\testcfg\testcfg.def for the usage of the IOPL
    attribute.  In your case, you need to specify IOPL against the _DATA
    segment.
==============================================================================

Q3. Also, is there a way to tell OS/2 not to use this memory for its usage?

A3. No, There is  no way.
==============================================================================

Q4. Does the Index maintain its previous values each time when the ISR() is
    called (like the static variables)?

A4. You could declare the variable as 'static' so that the variable will retain
    its value.




!STORAGE________________________________**********
June 16, 1995
QUESTION: (Ref: HK9)
How can I use DMA to read data from CD-ROM?


ANSWER:
DMA cannot be used from an application level.It is done at Adapter Device
Driver Level.  Only the Adaptec 154x adapter uses DMA.




!OTHER__________________________________**********
June 16, 1995
QUESTION: (Ref: HK6)
What socket services do I use with the ThinkPad 750?  I tried both currently
available (IBM2SS01.SYS and IBM2SS02.SYS) and neither seemed to enable the
PCMCIA card to allow my driver access to the card.

My driver, which is what I am using, works under several other socket services,
so I am assuming that the fault lies in the socket services area.  I could be
wrong.

I have searched all Bulletin Boards related to IBM and have found nothing.
I'm sure I could have missed something.


ANSWER:
PCMCIA installation support is available from the OS/2 BBS.  The phone# is
(919) 517-0001 and the filename is OS2PCM.ZIP.

The socket services you mentioned are the correct ones for the ThinkPad.  They
should be used as follows:

IBM2SS01.SYS for ISA Systems
IBM2SS02.SYS for MCA Systems




!STORAGE________________________________**********
June 16, 1995
QUESTION: (Ref: HK4)
1) I'm trying to make a call to DevHelp_AttachDD from FS_INIT.  To make a call
to the DevHelper Functions, I have to save the 'void (*DevHlp)()' paramater in
FS_INIT.  But how can the 'dhcalls.lib' from the latest DDK (included in
Devcon 5) 'know' that I saved this pointer??  I saved it to DevHelp,
Device_Helper, etc and still got a crash (although this could be a completely
different problem :-) ) is it safe to use the 'dhcalls.h' included in the
latest DDK?

2) I was wondering about the other IFS included in OS/2.  The CDFS.IFS for
example seems not to access the SCSIMGR$ or any other Device.  But how does
this IFS handle the CD?  Is it not necessary to open a device like the SCSI or
ASPI manager to do the I/O operations ?

3) As far as I understood, the IFS won't get a drive letter until FS_ATTACH is
called.  Does OS/2 call FS_ATTACH at some initialisation point or is this done
by other programms?  (Well exectuing a programm that attachs itself to the IFS
doesn't look very system integrating to me :-))

As far as I know now, to write an IFS involves the following steps:  (please
correct me if I'm wrong or missing something)

4) To 'allocate' a drive letter and to do basic I/O, I have to write a DMD.
Access to ASPI is not available in the DMD and all I/O is to be done with the
appropriate ADD.  (i.e.  AIC7870.ADD).

I have to write the IFS which connects to the DMD mentioned above.

The whole initialization of the above would look somewhat like this:

a) The DMD scans for connected physical Devices (by examining the adapter
   device class tables), for example a tape device.

b) Reserving a drive letter, e.g.  F:  At this time, the drive F:  is known
   to the system.(?)

c) In FS_INIT, the IFS checks/connects to the DMD.

d) At the first access of drive F:  (e.g.  typing 'f:'  in a shell) the IFS
   receives FS_MOUNT.  The IFS now has to handle all further access to the
   drive.

e) Integration into the WPS is done through creating the appropriate WPDrives
   class.(is this step necessary?)


ANSWER:
1. You MUST name the ULONG variable where you SAVE the DevHlp pointer the SAME
as the dhcalls.lib expects..

2. OS2CDROM.DMD is a BLOCK device driver, and is assigned drive letters when
it initializes.  CDFS then goes and queries the drive letters it is to manage.
OS2CDROM.DMD sends SCSI-2 IORBs to the driver that registered its CDROM device
classes that OS2CDROM.DMD manages.


3. Remote IFS (those with the Remote bit set in the FS_ATTRIBUTE do not get
drive letters assigned til FS_ATTACH time, LOCAL IFSs do NOT get FS_ATTACH
calls, they get FS_MOUNT calls.



4. ASPI IS available IF OS2ASPI.DMD is loaded and ready before your device
driver is.  OS2ASPI is callable thru the Adaptec documented inter device
driver call (IDC) mechanism at ring 0 ONLY.


a) Correct, If it supported TAPE devices.

b) BECAUSE the DMD (device driver) is marked as a BLOCK device in its device
header, it gets passes THE NEXT drive letter AND a UNIT COUNT of ONE, the
driver modifies this to the CORRECT unit count.

c) Correct, the DMD should supply an IOCTL call interface to provide the query
info.

d) All LOCAL (non-remote) IFSs will be called in order of appearance to CLAIM
the partition being examined.  One could call ASPI directly from here if
desired without need of a DMD.  this 'first' access is WELL before any user
could type 'F:'  on a commandline.

e) If the device is not a STANDARD DISK device, then yes, you will have to
either answer the DosDevIoctl calls sent to the normal devices, or make a new
subclass of wpDrive, using WinReplaceObjectClass() to insert YOUR class code
as wpDrive class.




!VIDEO__________________________________**********
June 16, 1995
QUESTION: (Ref: HK1)
I've been looking at the DDK Version 2 along with the source code for the
ET4000/W32P WARP driver with an eye toward determining what tasks need to be
accomplished to get a WARP driver for a new chipset.  In particular, in the
S3-Initializing the accelerator section of the Display Driver Reference Book
on point 5 - you suggest removing the DMS32CallBack((PFN)SwitchToChosenMode)
from QueryAndSelectNativeMode and essentially put logic in the PM driver to do
the setmode until the new base video has been completed for the new chipset.
I tried to follow the logic in the driver from the call to
DMS32CallBack((PFN)SwitchToChosenMode).  I looked at the logic DMS32CallBack
in setmode.c and need an explanation of what is happenening when the call
DMS32CallBack((PFN)SwitchToChosenMode) is made from QueryAndSelectNativeMode.

1) Where is the logic that actually does the setmode?  Is the source code for
it in this DDK ?

2) Where do we leave the PM driver to do the setmode and where and
how do we return?


ANSWER:
The SetMode logic for the S3 driver is in the base video handler.  The PM
driver calls the base video DLL to set the mode.

The setmode logic in most drivers is in base video.  Some drivers call a PDD
to set the mode and others code it right in the PM driver.  It is really up to
the driver writer.  But our samples use base video to set the mode and I feel
this is the way you should proceed.

If Vio call is issued to set the mode, the call is serviced by the base video
handler, such as BVHSVGA or BVHVGA.  Base video handlers are chained, so if a
handler doesn't support the function it can pass it on.  The handlers are
installed via a VIDEO_DEVICE statement in the CONFIG.SYS.  The source for all
IBM shipped base video handlers is on the DDK.

The BVHSVGA which is shipped by IBM is generic, meaning that it imports all of
its device specific functions from VIDEOPMI, the parser which handles the PMI
flat file and PMI binary modules (if any).  The PMI is not using the BIOS,
unless you have a way of executing BIOS in protect mode,(which is not
recommended) which then can be used in the imported PMI binary (a DLL such as
IBMGPMI.DLL).




!OTHER__________________________________**********
June 16, 1995
QUESTION: (Ref: HJ7)
My attempts at using OEMHLP$ to query the PCI BIOS are not working.

SAMPLE CODE 1 -- Attach to OEMHLP$ from the DD
(code removed by DDSC Team)

SAMPLE CODE 2
(code removed by DDSC Team)

SAMPLE CODE 3
(code removed by DDSC Team)


Questions:

1) In Sample Code 1, DevHelp_AttachDD always returns true (0x8048 I believe).
The DOCS specified that AttachDD could only be called from a BASEDEV.  Is
there anything special necessary to install the DD as a BASEDEV?

2) In Sample Code 2, the open of OEMHLP$ and the first IOCtl return SUCCESS.
However, the data area of the IOCtl is not filled in and if the data area is
initialized nonzero for the IOCtl, only the first two parameters are reset to
0, the remaining data area is untouched.  This has been tried on Version 2.11
rev 6.660 and also WARP with identical results.

Is there a fundamental problem with this approach?


3) In sample code 3,
 A. What can be done to get this working?  I have two different DOS
    utilities which can:

    a) Find the device of vendor_id=0x10e8 and device_id=0x4750
    b) Find the DevFunc number of 0x88.
    c) Read the configuration registers.


 B. Why do calls to FIND_PCI_DEVICE currently lock the system on about 1 out
    of 20 calls?  Invalid parameters?


ANSWER:
1. The IDC approach could be used from Ring 0. If your driver uses the DEVICE=
statement, the AttachDD could be used onlt at Task time(the INIT is at Ring
3).  If you have to use AttachDD at INIT time your driver should be a BASEDEV.

The Device Name should be 8 characters -"OEMHLP$ " and not "OEMHLP$".

Base device drivers are OS/2 drivers that are needed during the OS/2 boot
sequence.  They are loaded by way of BASEDEV= keywords in the CONFIG.SYS.
BASEDEV= statements cannot contain drive or path information because OS/2
cannot process such information at the stage of startup when BASEDEV=
statements are processed.  The root directory of the startup partition is
first searched for the specified file name, then the \OS2 directory of startup
partition is searched (in WARP \OS2\BOOT directory is also scanned for
BASEDEVs).

Base device drivers are initialized at ring 0 and can call the IDC entry point
from the INIT routine.  The INIT request packet command code is 0x1B rather
than 0x0.

An adapter device driver must identify itself as a participant in the adapter
device driver strategy by setting the following bits to 1 in the device driver
header.  The bit-numbering convention is that bit 15 is the most significant
bit in a WORD, and bit 31 is the most significant bit in a DWORD.

      - Device attribute field - Bits 15, 8, 7
        Bit 15 indicates a CHARACTER device driver. Bits 8 and 7 define the
        driver as a Level 3 device driver, which indicates usage of the DWORD
        capabilities bit strip in the header file.

      - Capabilities Bit Strip - Bit 3
        Bit 3 indicates that the driver is participating in the adapter
        device driver strategy which, in turn, selects an alternate INIT
        request packet format from the kernel.

      - INIT request packet format
        The INIT request packet for a driver that has identified itself as an
        adapter device driver (through bits set in the device driver header as
        described above) corresponds to the RPINITIN structure defined in
        REQPKT.H, supplied with the IBM Developer Connection Device Driver Kit
        for OS/2.

For details refer to the Storage Device Driver Reference - Chapters 2 & 3. You
could also refer to the Sample BASEDEV Codes in the DDK, for example,
DDKX86\SRC\DEV\DASD\CDROM\OS2CDROM\CDINIT.C

There is nothing wrong in your code.  The Major Version,Minor Version & the
Last Bus are Unsigned Char (take this into account in your printf).


(for sample code 3)
Since you are compiling your application ( Sample 3 code ) with the 32 bit IBM
C compiler (ICC /Ss /Ti+ oemhlp.c), pay special attention to all the shared
data structures ( _PCI_PARAM1, _PCI_PARAM2, _PCI_DATA1 ..etc) because the data
alignment generated by a 32 bit compiler is different than a 16 bit Compiler (
which is used to develop Device Driver code) due to different default byte
alignment strategies used by both type of compilers.  2. Suggest you use the
IPMD debugger to display/verify the data structure in memory, before you issue
the DosDevIOCtl calls to the PDD's.  Ensure that the data structure of the
appropriate parameter and data blocks match with the requirements of the
DosDevIOCtl interfaces and the requirements of the appropriate DD ( i.e.
OEMHLP$)

In case of discrepancies try using the "_Packed" reserved word before the
struct declaration or use the appropriate /Spx switch of ICC compiler

Refer : IBM Cset/2 User's Guide for more details.




!OTHER__________________________________**********
June 16, 1995
QUESTION: (Ref: HH7)
At present now I am searching for the PCMCIA card/socket services programming
spec online.  If there is an electronic form of this and you know where to
find it I'd be greatful if you'd steer me that way.


ANSWER:
We don't know of any electronic form of programming spec that you are looking
for.  The only pcmcia material that we have in electronic form is the I/O
Device Driver Reference Manual which is in .INF format on the DDK.




!OTHER__________________________________**********
June 16, 1995
QUESTION:  (Ref: GV5)
I/O Base port assignment does not work correctly.  If you use the "assign me a
port" request in the request I/O function (CS_REQUEST_IO -- PORT1 param- eter
= 0 ), you will be returned a port value.  Unless this port value matches the
port # found in the configuration tuple (CISTPL_CE +4B), you will not be able
to access the card.  I have altered the configuration of the tuple and have
found that the 1st choice of port configuration values is followed, not the
assigned port value returned by CARD SERVICES.


ANSWER:
This is how it is supposed to work:  The client driver reads the tuple
information to figure out what configuration should be set.  Then the client
driver calls into card services with the port that is wanted.  Card Services
can either say success (meaning no other device is using that port) or failure
(meaning another device is using that port).  If the client driver calls into
card services with port1 parameter=0, this means give the client the first
port greater than 100h that is not in use.  Card services never checks to see
if this port can be configured to this device.




!OTHER__________________________________**********
June 09, 1995
QUESTION: (Ref. HM8)
1. I am creating a BASEDEV PDD based on the PRINT01.SYS parallel port driver.
If I run this driver on Warp, I get the command line parameters (/IRQ) as
expected in the init packet.  If I run this driver on OS/2 2.1, I do not get
the command line parameters.  Does OS/2 2.1 support passing the command line
params in the init packet?

2. Is there an updated PDD reference showing the strategy commands like
BaseDev Init (0x1B) that are not documented in the PDD Ref on the Devcon DDK
2?


ANSWER:
1. The OS/2 2.1 and earlier versions of the parallel port device driver
replace the command line pointer in the init packet with a special pointer.
The special pointer points to the PRTMONBUFSIZE= parameters from config.sys.
In OS/2 Warp, the special pointer was enhanced to contain the command line
after the PRTMONBUFSIZE parameters.  The command line parameters are not
passed to the OS/2 2.1 or earlier versions of the parallel port device driver.

By turning bit 2 (zero based) to zero in the capabilities bit strip at the end
of the device driver header, the device driver should receive the command line
parameters.  The downside to this is that the driver will not receive the
PRTMONBUFSIZE= parameters.

2. The DD command 1BH will be in the future release of the PDD reference.




!OTHER__________________________________**********
June 09, 1995
QUESTION:  (Ref: HI8)
We need to know where to incorporate the driver version number.


ANSWER:
You could refer to the section on "Module Level Version Control" in
ddkx86\book\useddk.inf.  This book is available online as part of the DevCon
DDK.




!STORAGE________________________________**********
June 09, 1995
QUESTION: (Ref: HI1)
I am using an ADAPTEC (1520/1540) and FD8XX SCSI card to an HP SCANJET IIIp.
Under DOS 6.2, with ASPI2DOS or ASPI4DOS, I can always get the actual length
transferred on a read by using the RESIDUAL bit on an ASPI command.  Using
OS/2 Warp, I have tried the following:

- ASPIDRV (from the Adaptec ASPI OS/2 specs) and I always get 0 residual
  length.

- VASPI with DOS Session and I never get an updated length.

- Using the GENSCSI driver sending a read command directly I always get 0
  residual length in the TSB.

In all cases, I am using the raw SCSI read command (0x08 with SCB_6).  I
always get the data back with the correct length filled in the buffer and the
rest of the buffer untouched.

How can I get the OS2SCSI or OS2SCSI/OS2ASPI combination to actually report
the residual?


ANSWER:
Currently, the residual byte count is not set except in case of an error.




!OTHER__________________________________**********
June 09, 1995
QUESTION: (Ref: HH6)
We have an extreme need to be able to initialize our driver in RING 0 (at
least part of our driver needs to use RING0).  The PDD reference suggests that
BASEDEV drivers and/or ADD drivers initialize in RING0, but does not
elaborate.  The ability to start initialization in RING3 and then "callback"
RING0 code is also acceptable.

Documentation on how to produce BASEDEV or ADD drivers (if they will actually
fulfil my needs) or a method of doing a "RING0 CALLBACK" is urgently needed.

If worst comes to worst, the INIT COMPLETE entry can be used, but involves
changing many existing related drivers.


ANSWER:
For documentation about BASEDEV, refer to storage driver reference, Ch 2, 3.
You could also refer to the sample BASEDEV drivers in ddkx86\src\
dev\dasd\cdrom\os2cdrom\cdinit.c




!OTHER__________________________________**********
June 09, 1995
QUESTION:  (Ref: HH5)
Q1. There is a C source file named RMHELP.C which is a part of the DDK.  Since
    I didn't find any compiler definition, IBM or Borland, I assumed it to be
    the IBM compiler.

    When I tried to compile, I got an 'Unable to find #include file
    "RMBASE.H"'.  When I brought the RMBASE.H file into the same directory, I
    got 'RMBASE.H (167:5) a member declaration must include a name'.  I found
    another RMBASE.H on the DevCon DDK 1.0 cdrom in dir DDKX86\MMOS2\H that
    didn't include the two (2) problematic lines that caused the problem.
    When I compiled again the error disappeared but there were other errors.

    Is IBM C the correct compiler to use?

A1. RMHELP.C is available in:
     - \ddkx86\mmos2\samples\ad1848
     - \ddkx86\mmos2\samples\pastk
     - \ddkx86\src\dev\atcom

    RMBASE.H is available in:
     - \ddkx86\mmos2\h
     - \ddkx86\src\dev\resource\rsm_h

    These files require the MSC 6.0 compiler.  You could refer to the
    makefiles contained in the directories which have rmhelp.c.  Also, please
    download RMBASE.ZIP from the Main file area on the DUDE for additional
    information on RMBASE.
==============================================================================

Q2. Why is the RMBASE.H file incompatible with the source while the correct
    one is not copied from the cdrom during intallation?

A2. The incompatibility is probably becuase you are using CSet/2 instead of
    MSC 6.0.  You could probably port RMHELP.C to the IBM C Compiler before
    using it in your driver.
==============================================================================

Q3. The MSC 6.0 compiler is obsolete, I can't get it.  Which of the following
    compilers is preferrable as a substitute?

      - IBM C Set ++ for OS/2 ver 2.1.
      - BORLAND C++ for OS/2 ver 1.0.

A3. IBM CSet ++ for OS/2 2.1 and Borland C++ for OS/2 1.0 are both 32bit
    compilers and are not for use in writing 16bit device drivers.  Examples
    of 16bit compilers, other than MSC 6.0, are IBM C/2, Watcom C16, and
    Borland 3.5.




!OTHER__________________________________**********
June 09, 1995
QUESTION: (Ref: HH2)
I'm trying to write a .DDP file so it can be used on both OS/2 2.0 and 3.0.
My question is how can I specify in the FILE section such that my .ADD file
will be copied to either \OS2 (for 2.0) or \OS2\BOOT (for 3.0) directories?


ANSWER:
Refer to Storage Device Driver Ref.  ,Chapter - Installation of OS/2,DASD SCSI
& CD-ROM Device Drivers - Presence-Check Function.

:PRESENCECHECK
<your_program>

<your_program> would basically look for the OS/2 Boot Directory.If it exists
it would copy your ADD into the OS\BOOT Directory.If the Boot Directory did
not exist the ADD would be copied to \OS2 directory.




!STORAGE________________________________**********
June 09, 1995
QUESTION: (Ref: HH0)
I am working on a higher level aspect to my driver system.  I was wondering
whether a 'standard' tape drive interface exists.  If so, where is it?  I do
not see anything in the 2.0 manuals, and have not found anything in the ddk
yet.  Any comments suggests, or should I just pester the various backup
utility manufactures?  I am trying to do an online backup of a 'database' and
the 'normal' backup utilities usually want exclusive access to the files.  I
was hoping that a simple interface might exist that could be used to make life
nice.


ANSWER:
You could use the ATAPI CDROM filter as a guide in creating another filter for
IDE tape.  Using the latest DDK (has the source for full pack), the scenerio
would be that the tape filter would hook into the ibm1s506.add drive the same
way as the cdrom filter does.  Also, since the st506.add actually owns the
IRQ, we can have an interface card with both an atapi CDROM and IDE tape on
the same channel.  Each would issue suspends to the ibm1s506.add driver when
it wanted control.  If one filter has the st506.add driver suspended, the
suspend coming from the second filter should be queued up so that we can share
the resource.

For IDE - ATAPI driver \ddkx86\src\dev\cdrom\atapi
For SCSI - SCSI.SYS driver \ddkx86\src\dev\os2scsi
Ref : Storage Driver Ref Manual




!OTHER__________________________________**********
June 09, 1995
QUESTION:  (Ref: HG9)
I have developed several multimedia products such as MPEG playback & capture
card, Sound card, Fax/Modem/Voice board, etc...  Now I need to develop device
drivers for OS/2 WARP but I really don't know what sort of toolkits I need and
where I can get the information.  Would you please send me some information
that I can easily follow?


ANSWER:
There is a text file available on the DUDE which contains the type of
information you are requesting.  Please download NEWDDD.TXT from the INFO file
area on the DUDE.




!PRINT__________________________________**********
June 09, 1995
QUESTION: (Ref. HG8)
We are trying to support an existing Windows Printer Driver under WIN-OS/2.
This driver currently uses a VxD (for bidi communications) and VxDs are not
currently supported under WIN-OS/2.

We believe that the best approach to this would be to create a VDD or a
VDD/PDD combination to replace the VxD for WIN-OS/2.

What we cannot find is any information about how to set up a VDD so that it
provides exactly the same interface as provided by the VxD.  This would
require that the same Device ID would be available to the driver, together
with the same set of API functions.

Is there any information available about how to set up a VDD so that it
behaves like the equivalent Windows VxD?


ANSWER:
1. Your approach of replacing the VxD for the Windows Device Driver in
   WIN-OS/2 by a VDD/PDD is correct as OS/2 does not allow VxD's to run under
   OS/2 as it compromises system security and protection.

2. You do not use Device ID's for VDD as you would normally be using in the
   Windows VxD architecture ( in order to control VxD loading sequences etc.).
   VDD could support similar interface functionality for DOS and Windows
   applications as provided by VxD's under Windows.  For more information on
   VDD architecture and its applications refer to the following :-

   - VDD Reference Manual.
   - Source Listing of OS/2-WINOS/2 communication in the
     Developer Connection News (Disc 1) available in DevCon Vol-6
   - Display Device Driver Ref:Chapter-8 on Seamless Windows Support
     and releveant source files in DDK for Seamless Windows Support
     \ddkx86\src\vdev\vvideo




!I/O____________________________________**********
June 09, 1995
QUESTION: (HF7)
I Have a device driver up and going, for a serial (RS485) card, using the
Zilog 8530 SCC.  It is based on a pre-existing MS-DOS driver and the various
sample drivers.  The interrupt section is largely unmodified from the MS-DOS
version.  However, under OS/2, i only ever get ONE TX interrupt for each
WRITE.  Every time i open the device and WRITE, the first byte sent (by
non-interrupt code) always works.  The second byte, which is done in the
interrupt, sometimes works.  The equivalent code works under MS-DOS, and i'm
baffled.

Here are the relevant fragments of my driver;

Am using the Watcom compiler, so all the DevHelp funcs are replaced by DH
inline #pragmas...

Please note nothing is connected to the receive side, and i'm not yet working
on RX interrupts, since i can't even get TX to work.


in switch( rp->command )  section:               (code uses tabs = 8)
(txw_val is 64, txw_cnt is 4, the intent is to timeout quickly if the
 TX fails, but to keep timing out as long as the Ptxbfr is inc'ing)

(***code removed by DDSC for security****)

the intr-handler i'm actually using has debug stuff in it, which builds a list
of the interrupt values read from the UART in REG2, and i have the driver set
up to return that list on a READ, so i can get a real-time view of what
happened in the intr-handler.  Sometimes, i do get the TX_INT, and poke the
second byte out, but i never get the TX_INT for the second byte.  I'm
frazzled.

ANY help you can offer would be appreciated.


ANSWER:
From your code it is clear that you are outputting the first byte then issuing
the ResetUnderrunLatch command to register 0. Please check if you have enabled
the transmit empty interrupt in register 1. If not, you will not get any Tx
interrupt.

In addition to this whenever you select any register of 8530 SCC, you should
disable interrupts.  One possible method of transmitting first byte could be

        - disable interrupt
        - enable Tx INT to register 1
        - output byte
        - transmit underrun latch to register 0
        - enable interrupt

Verify if you are getting the interrupts.

In the time out loop when calling ProcBlock, you could follow the following
method -

        - disable interrupt
        - while (need to wait)
        - block
        - disable interrupt
        - disable interrupt

Refer to description of ProcBlock in the PDD reference.

In you ISR the loop is not required at all.  Since an ISR is invoked whenever
an interrupt occurs.  You need not wait for an interrupt.

If the device driver is for ISA bus machine, the device driver's interrupt
handler is called with interrupts disabled.  Make sure that the interrupts are
enabled before coming out of the ISR.  You could refer to interrupt section on
the Mastrianni's book.


FOLLOW-UP QUESTION:
Your suggestion about disabling intr's around register access is a good idea,
and one that slipped right passed me.  I have added that to the driver.

Turns out, however, that the real problem was the "known working code" I
started with did not delay between register accesses, which apparently
violates the SCC recovery times.  When I added delays, the TX stuff worked
right away.

1. But now I have another problem.  I wrote my READ section to return the #
bytes in a message, if there was one, but return an error if a timeout occurs
while doing the READ.  I've just spent the last 4 hours finding out,
apparently, if a driver returns less than the number requested, OS/2 calls
READ again.  True?

Therefore, the driver returns the whole message on the first call, but on the
second call times out, returns an error code, which the application gets.  The
data is actually in the buffer, so I could do something sleazy like ignore the
read() return code, but...  I can't find anything in the online docs what is
"normally" done here.

2. Should the driver just return 0 the second time, or is there an "error"


ANSWER:
1) It is true that the driver is called again if driver returns less than the
requested number with return code successful.  If driver returns with error
code then the the error code is returned to the application.

2) Your driver could return the following return code in the status field of
the request packet for the READ strategy routine.

RPERR 0x8000  error occured
RPDEV 0x4000  error code
RPBUSY 0x0200 device busy
RPDONE 0x0100 done bit     (to be set always, even if error)

Bits 0-7 of the status word contains the error code if RPERR is set.

In your case ERROR_CHAR_CALL_INTERRUPTED (11h) should be returned.

Ref : "Writing OS/2 2.1 Device Driver in C", Steve J. Mastrianni, Ch-6
      "Device Driver Strategy Command" for standard device driver error codes.

      Ch-7, section "Device Driver Operation", subsection "IOCtls" for sample
      code for error returning.




!STORAGE________________________________**********
June 09, 1995
QUESTION: (Ref: HF4)
Q1. I want to expand my OS/2 Warp device driver to run under OS/2 2.11.  I
    have problems under OS/2 2.11 using the PCI IOCtl.  Our PCI Version is
    2.16 and the error code of the DosDevIOCtl is 65283.  With OS/2 Warp I
    have no errors with this PCI Version.  What can I do?  How can I replace
    the OEMHELP device helper services for PCI under OS/2 2.11?

A1. The OEMHLP Device Driver is a part of OS2LDR and hence comes with OS/2.
    There is no need for you to replace the OEMHLP services.  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
==============================================================================

Q2. Aare there any source code samples on this topic?

A2. The OEMHLP Device Driver could be accessed through:

      - Ring 3 - DosOpen/DosDevIOCtl - Refer to Mastrianni's book, "Writing
        OS/2 2.1 Device Drivers in C"

      - Ring 0 - DevHlp_AttachDD - IDC Approach - sample code available on the
        DUDE BBS (OEMHLP.ZIP & OEMBASE.INF in the Main File area)




!STORAGE________________________________**********
June 09, 1995
QUESTION: (Ref: HE5)
1. I wonder whether I can take the NEW IBM1S506.ADD (the IDE device driver for
OS/2 3.0 Warp) to be a common driver for 3.0, 2.1 and 2.0 or not.  I try to
install the NEW IBM1S506.ADD to the OS/2 2.x.  It boots up and seems good.  I
would like to make sure the possibilities of using NEW IBM1S506.ADD as a
common driver for different version of OS/2.  Although I did the test (install
the NEW IBM1S506.ADD to the OS/2 2.x) and it seemed OK.

2. I installed the NEW IBM1S506.ADD to the OS/2 2.x, but I just can't see the
IDE type CD-ROM when I attached the CD-ROM on the controller.  It is
reasonable because the OS/2 2.x don't support the IDE type CD-ROM drive.  I
would like to know if there is any way to support the IDE type CD-ROM in the
OS/2 2.x system.  If YES, I would like to know how.


ANSWER:
1.The Warp level driver will run on OS/2 2.x

2. On the OS/2 2.x System upgrade OS2CDROM.DMD,the IDE CDROM Filter and the
IBM1S506.ADD to Warp level.  Once you have all these 3 drivers at Warp
level,you should'nt have any problems supporting the IDE CDROM on OS/2 2.x




!PRINT__________________________________**********
June 09, 1995
QUESTION:  (Ref: HD5)
I have a problem obtaining printer default settings in the FILL_PHYSICAL
subfunction of OS2_PM_DRV_ENABLE.

In order to load default settings from the OS2SYS.INI file, I need to build
a key name.  The format of the key should be:

  PM_DD_<printer name>,<hardcopy driver>.<device name>.

 (see in page 146 of the Presentation Driver Reference S10G-6267-01)

The pszLogAddress of the PDEVOPENSTRUC parameter passed to FILL_PHYSICAL
should point to <printer name> which is the physical name of the object
created on the WorkPlace Shell.

The Printer Test Tool (PTT) Version 1.82 passes <printer name> as
pszLogAddress when OD_QUEUED is selected and <port name> when OD_DIRECT is
selected in the PTT configuration dialog.

Q1. Why does PTT pass the port name instead of the printer name when OD_DIRECT
    is selected?

A1. PTT passes the port name (such as LPT1) when OD_DIRECT is selected.  The
    driver can use the file system PrtXXX interface to pass the output to the
    PDD.  If OD_QUEUED is selected, it passes the printer name so that it goes
    to the corresponding spooler file.
==============================================================================

Q2. If this is not a failure of PTT, what am I doing wrong?

A2. Please check that the key name is properly built into your OS2SYS.INI.
    You can examine the keywords using the INIMAINT.EXE utility.  You can also
    display what parameters are received in DEVOPENSTRUC in the
    FILLPHYSICALDEVICEBLOCK subfunction.  If you are not getting the expected
    parameters, check the argument types.
==============================================================================

Q3. For OD_DIRECT it will not be possible to come up with a unique printer
    name because multiple printer configurations can be created for the same
    device on the same port.

    I can, for example, create a 'Printer1' with a portrait page orientation
    and a 'Printer2' with a landscape page orientation.  If an application
    opens a DC with OD_DIRECT, then the printer driver will not be able to
    find the correct defaults in FillPhysicalDeviceBlock unless they are
    passed in DRIVDATA.

    How should a printer driver behave in above situation?

      Should it:
      1) use the defaults of the first printer attached to the port
      2) return an error
      3) etc...

A3. If there is not enough information to determine the proper printer, then
    use the "set default" defined printer for its options.  If that printer is
    not yours, then use the first printer that you find.
==============================================================================

Q4. I only want to support OD_DIRECT.  Is it possible for the printer driver
    to overwrite OD_QUEUED with OD_DIRECT?

A4. Normally it is not possible to have only OD_DIRECT support.  This will
    break network printing.  The printer name for a direct name is not enough
    information for routing to the network printer.
==============================================================================

Q5. Is it possible for an application to change the job properties
    (orientation, form, etc...)  during printing without creating a new print
    job?

A5. It is not possible for an application to change the job properties during
    printing without creating a new print job.  Refer to pp.142 - 147 in the
    presentation reference.




!STORAGE________________________________**********
June 09, 1995
QUESTION: (Ref: HD4)
The DMD under development manages optical media with a 1 KB sector size.  If
the "DIR" command is issued against the drive letter being managed by the DMD,
a succession of calls are made to the DMD.  These include Reset Media, IOCtl
Category 8, Function 63h (Get Drive Parameters), Read Sector 0, and Build BPB.
The DMD is responding to all of these calls correctly.

OS/2 then issues IOCtl Category 8, Function 64h (Read Track) with a request
for only the first sector, but the SectorSize field in the TrackTable is set
to 0200h (512 bytes) when calling into the DMD.  Since the DMD is managing
sectors of 1024 bytes, there is no clear procedure for a response.  The FAT
file system cannot be mounted onto the disk, and the information in the boot
sector (volume serial number, geometry) is ignored.

It seems to me that, since the Read Track call occurs after OS/2 has been
told that the sector size is 1024 bytes in response to BuildBPB, then the
SectorSize field should reflect the proper 1024 bytes instead of 512 bytes.


ANSWER:
When IOCtl category 8, function 63h is issued, what is the value returned in
"Device Type" field in the data packet ?  In your case it should be 8 (R/W
optical disk).

If not, you could try issuing IOCtl category 8, function 43h (set device
parameters) specifying 'Device Type" as 8 and "Bytes per sector" as 1024 in
the extended BPB in the data packet.  Ref :  PDD reference, Ch-10 "generic
IOCtl commands"

Also, check if 'UnitType" field in UNITINFO structure, which is part of
ADAPTERINFO structure, which in turn is part of DEVICETABLE structure is set
to UIB_TYPE_OPTICAL_MEMORY (defined in ddkx86\src\dev\dasd\diskh\iorb.h) Ref :
Storage reference, Ch-4, section on "DEVICETABLE structure overview"




!STORAGE________________________________**********
June 09, 1995
QUESTION: (Ref: H98)
One of the software products we develop and market works closely with the
Pioneer DRM-600 6 disk CD-ROM changers.  Currently we have two versions of our
application, one for OS/2 and the other for DOS.

The problem is all of our customers have a need to connect several Pionner
changers to their computer.  Under DOS, this is not a problem for them
(details follow).  Unfortunately, we have not been able to find a way for them
to do so under OS/2.

Pioneer has made available a "single drive letter" driver for DOS which allows
each changer to be assigned to one logical drive.  They also provide an
XDISK.EXE program which takes a drive letter and disk number as parameters and
sends a command to the changer to switch the current disk.

This means, under DOS, our customers can have virtually as many CD-ROMs
available as they want, which makes them very happy.  In fact, most of them
have 6 or more Pionner CD-ROM changers per computer!  We have been trying to
find a way to have the Pioneer CD-ROM changers emulate this behavior under
OS/2.

As you are probably aware, the Pioneer changers must be connected to Future
Domain SCSI controllers.  The Future Domain OS/2 device driver (FD16-700.ADD)
defaults to assigning one drive letter to each changer.  The problem is, we
see no way to switch the current disk in the changer.  In fact, the only way
we have been able to access the other disks at all is by adding the /ET switch
to the device driver command line.  This option causes the device driver to
map all 6 disks in the changer to seperate logical drives.  Unfortunately,
this limits the number of changers that can be connected to a single computer
to 4!

Clearly, we cannot limit our customers to 4 changers per computer; they would
prefer to stay with DOS than to load multiple computers with OS/2 and seperate
their CD-ROM changers.  Therefore, we must find a way to provide single drive
letter support under OS/2.

It is our assumption that the OS/2 SCSI device driver (OS2SCSI.DMD) or the
Future Domain device driver is capable of issuing a "switch disk" command.
The problem is, we do not know how to send it this command, or the specifics
of what should be sent.  It seems that the IOCtl OS/2 API commands are
designed for this purpose but we lack specifics on their use in this regard.

Could you possibly assist us in resolving this problem?  We would greatly
appreciate any suggestions you have.


ANSWER:
Using the /ET (Embedded Target) command should get you the single drive
letter.  However, there is no support for any proprietary SCSI command to
switch which disk is currently selected.

One could write a small filter and an application to inject the change command
to the drive.  Write an OS/2 Filter ADD driver that can combine the
independent LUNS reported by the DRM-600 into a single CD-ROM physical device.

The filter would need to:

1.  Provide a private IOCtl interface to an application that would allow the
    user to select the appropriate CD-Drawer.

2.  Simulate a media change indication back to the CD-ROM manager when
    the user changes the CD selected so that new CDROM directories are read.

3.  Provide IORB routing based on the user selected CD-Drawer.

This would involve directing the IORB to the ADD/ADDUnitHandle corresponding
to the Target/Lun for the selected CDROM Drawer on the DRM-600.

The filter implemented should be useable across all OS/2 SCSI ADD drivers that
provide multiple lun support and would be compatible with the existing
OS2CDROM manager.

See the lockdrv filter on the DDK for a sample of the filter, then add generic
Ioctl support in the request packet processing of the filter.  DosOpen the
filter device name (it's a standard character device driver) and send a user
defined Ioctl command to select the drive.




!OTHER__________________________________**********
June 09, 1995
QUESTION: (Ref: H15)
It was mentioned to me that the current version of PCMCIA.SYS does not "use" a
interrupt level for socket management functions.

I want to be able to have the device driver I am writing tell the socket
controller not to use an interrupt level, but to do that I need to know that
the card services is polling for status changes and not waiting for changes in
its interrupt handler.  Is there a way for the socket services driver to
obtain this information from the card services driver, (i.e.  version level,
etc)?


ANSWER:
Refer to the PCMCIA Card Services Specification - you could use the
GetCardServicesInfo Function from your Socket Services Driver.  This function
returns the number of logical sockets installed and information about Card
Services presence, vendor revision number and release compliance information.




!STORAGE________________________________**********
June 05, 1995
QUESTION: (Ref: HL7)
We have a customer that is having some compatibility issues with Warp's IDE
driver (IBMs506.ADD) and our SCSI driver (xxx.ADD).  I just want to find out
your thoughts on this problem.

During OS/2 Warp Install on a PCI system the following behaviors were
observed:

Assumptions:

- Installing OS/2 to an IDE drive from a SCSI CD-ROM

- SCSI HDD is also connected as a secondary drive

- "BASEDEV="xxx.ADD" is the first line (before IBMs506.add) in CONFIG.SYS on
   DISK1

Observations:

(1) System boots OS/2 from the install floppy disks.  Running OS/2 FDISK shows
the SCSI drive as being first and the IDE second, which is not correct.  The
system should hang in this scenario but it doesn't.  Our driver loads fine and
OS/2 installation begins.

This is a potential problem because OS/2 should see the IDE drive as the first
drive no matter where the our driver statement has been placed in CONFIG.SYS.

(2) When "BASEDEV=xxx.ADD" is placed after the IBMs506.add statement in
CONFIG.SYS on DISK1, OS/2 FDISK shows the IDE drive as being first and the
SCSI second, which is the correct drive assignment.

Note:  When a drive is added to the system after OS/2 has been installed to
one drive, the drive letter assignment is changed.


What do you think the problem is?  Is it by design that the IBMS506.ADD should
always be declared first before any other SCSI .ADD driver, or is it the int
13h SYSTEM and SCSI BIOS not giving the right information to OS/2 that causes
a problem with drive assignment (i.e.  SCSI drive becomes drive 80h and IDE
drive becomes drive 81h)?


I hooked up an HP PCI system with a 170MB IDE drive and our PCSCSI adapter
with a SCSI CD-ROM drive.  The setup went smooth and the installation went
through (I just have to add xxx.ADD in the config.sys on one of the
diskettes).  I have noticed in looking at the config.sys file that our driver
is in front of the IDE driver.

The next thing I did is hook up a 500 MB SCSI hard disk drive to the PCSCSI
adapter.  The 500MB SCSI hard disk drive already has WARP installed.  So now,
the HP system has an IDE drive, a SCSI drive, and a CD-ROM drive.

With this configuration, If I run OS/2's FDISK in the OS/2 box.  The IDE drive
is assigned as drive 2 ("D") and the SCSI drive is assigned as drive 1 ("C").

Now, If I change the order in the config.sys file, I put the IDE driver first
then the xxx.ADD driver next.  The drive assignment changes, the IDE drive is
assigned as drive 1 ("C") and the SCSI drive is assigned as drive 2. ("D")

Another thing, that I did is to take the our SCSI card out of the picture and
use the Adaptec's PCI card AIC7870.ADD and run into the same process.  I do
see the same results.

What I have noticed with OS/2 2.x, the install utility appends the driver at
the end of the config.sys file (i.e.  the IDE driver is loaded first before
the SCSI ADD driver).

I just want to confirm with you the behavior we are seeing is are normal (i.e.
that's the way OS/2 Warp works) or there is a way we (i.e.  the system BIOS or
the OS/2 driver) that the SCSI drive is the second drive on the chain (i.e.
int 13h drive 81) and assign it as drive "D".


ANSWER:
The dasd managers and other dasd drivers return the number of units that they
control, at init time and are made available in the unit parameter table.  The
kernel during init time uses this table and assigns the drive letters.  The
kernel goes through the table and assigns drive letters to the primary
partitions first and then assigns drive letters to the logical partitions.

The drive assignments are not under the control of the device drivers.  The
user may be able to reorder the drive assignments by ordering the ADDs in a
certain way or reordering the partitions.  Doing this may not be a permanent
solution.  Everytime a new disk is added or a disk is partitioned, the order
will change,unless the new ADD driver is appended to config.sys.

If several BASEDEV= statements load file names with the same extension, those
files are loaded in the order in which they are encountered in the CONFIG.SYS
file.  So in your case the loading order should be -

1) IBMS506.ADD
2) xxx.ADD




!OTHER__________________________________**********
Jun 05, 1995
QUESTION: (Ref: HJ8)
The Display device driver reference (DISPLAY.INF), under the section "PMI
Language Constructs + Imported Functions" contains the following statement:

"Full programming guidance and sample source for the imported binary objects
will be available in the first PMI development kit."

When will this "PMI development kit" be available, and where should I look for
it?


ANSWER:
The PMI Development Kit does not exist, nor there are plans to have one. The
documentation error is being corrected.  Relevant PMI information is available
on DevCon DDK 2.

1. DevCon DDK 2.0 Display Driver on-line reference contains the new PMI syntax
as well as VIDEOPMI's and VIDEOCFG's calling interface.

2. Run DevCon DDK's svga.exe on any non ICD clock based S3 928, S3 864, or
Tseng W32 for a working sample that contains all of the refresh programming
within the file.  Run it on any ICD based S3 or W32 or on any Cirrus 3x to get
a sample which imports refresh programming from the IBMGPMI.DLL.  Run it on
Diamond Viper 9000 VLB for a sample of memory mapped PMI file.

3. SVGADEFS.H header file features all of VIDEOPMI, VIDEOCFG API's as well as
associated structures.  It also contains chip-ID, DAC and other adapter
related lists.  The file is imported by BVHSVGA.DLL, PMDISPLAY.DLL,
VIDEOPMI.DLL, VIDEOCFG.DLL, SVGA.EXE, VSVGA.SYS and any other component which
wishes to use VIDEOCFG or VIDEOPMI's interfaces.

4. Display driver reference lists the binary files that compose the base video
subsystem and explains the difference in the installation between 3.0 and 2.1.
Search for VIDEOCFG to see all references.




!STORAGE________________________________**********
June 05, 1995
QUESTION: (Ref: HJ6)
We have been developing a filter device driver to operate ATAPI tape drives
through the IBM1S506.ADD driver.  Our driver thus far has been based off of
the IBMIDECD.FLT driver found on the latest version of the DDK(DEVCON #2).

So far so good, until we applied Warp fixpack #5.  Now our driver traps (trap
0003) at boot.  This same error occurs when we compile the IBMIDECD.FLT driver
as supplied in the DDK, generating a breakpoint trap in the HookIRQ() in
ATAPIGEN.C.

I searched and found APAR PJ17331 which states that both IBM1S506.ADD and
IBMIDECD.FLT have been updated, and that older versions of IBMIDECD.FLT will
no longer function with the newer IBM1S506.ADD.  My question then is what
changed so I can update our filter driver to work with the newer IBM1S506.ADD?


ANSWER:
APAR PJ17331 - Two IDE CDROMS on single channel causes trap Slight
modification were done in the IRQ ownership.  Because of this, the
IBM1S506.ADD will need to be updated along with the IBMIDECD.FLT.  As a net
result, the new IBM1S506.ADD will not work with an older filter and the new
filter will not work with the old .add.

Also Remove CTX Hook method of switching IRQ owners and add in its place,
passing of the IRQ handler function address in the suspend command.  With this
method, a driver passes it's IRQ handler function to the function he is
suspending.  When the suspended driver recieves an interrupt, he calls the
passed in function rather than it's own.




!OTHER__________________________________**********
June 05, 1995
QUESTION: (Ref. HJ5)
Need an example of how to use DosPhysicalDisk with function 2 (Get a handle to
use with DevIOCtl).  Keep getting parameter error rc =87.  Tried 8,000,000
combinations of parameters with no luck.  Suspect that the ASCII string
parameter is the culprit.

1. What does 1-based mean?
2. What does partitionable mean?  Please send an example.


ANSWER:
1. 1-based means count starts from 1 and not from 0.If you have 1
partitionable disk, the disk number is 1.

2. A partitionable disk is a physical hard disk that can be formatted into
partitions (logical drives).Run "fdisk" to find how many partionable disks are
on your system.You could have 1 Partionable Disk and two logical partitions on
it.

Example code :

------------------------------------------------------------------------------
-
   #define INCL_DOSDEVICES   /* Device values    */
   #include <os2.h>
   #include <stdio.h>

   main()
      {
       USHORT  usHandle;
       UCHAR   auchParmPtr[3];
       USHORT  usParmLen;
       USHORT  rc;

       strcpy( auchParmPtr, "1:" );    // Partition number

       usParmLen = strlen( auchParmPtr ) + 1;  // +1 for null byte
       rc = DosPhysicalDisk(INFO_GETIOCTLHANDLE,
            (PVOID) &usHandle,
            sizeof(USHORT),
            (PVOID) &auchParmPtr,
            usParmLen);
       if ( rc  )
       {

           printf("DosPhysicalDisk error: return code = %u\n", rc);
           return 1;
       }
           printf("Handle = %u\n", usHandle );
           return 0;
     }




!OTHER__________________________________**********
June 05, 1995
QUESTION: (Ref: HJ1)
Q1. Will there be an automated function available soon that identifies the
    chipset and then installs the correct Card and Socket Services associated
    with the current OS version?  Is there something now?

A1. Presently, there is no utility available to identify the chipset and link
    them to the appropriate OS/2 drivers.
==============================================================================

Q2. I have a laptop from Midwest Micro, P5-90 based, that indicated that the
    chipset was Data Book.  We loaded the required files from the list of
    chipsets (IBM2AMB1.sys / IBM2CAD1.sys -- we tried both ) and they failed
    to load.  We then called Midwest Micro and they indicated that the chipset
    was Cirrus Logic.  Well this didn't work either, is there something
    special here?

A2. The Midwest Micro earlier versions had the Data Book chipset and you would
    use IBM2AMB1.  However, the later versions have the Cirrus Logic chipset
    and you would select the Matsushita PCMCIA System during the install.




!OTHER__________________________________**********
June 05, 1995
QUESTION: (Ref: HI9)
I have read the Display Driver reference section, 16-bit VGA display driver,
"Phase Relationship between Source and Target Bit Maps", and I find I do not
understnad the example scan line cases in figures 1-4 through 1-9.  Sometimes
the phase number refers to the number of left rotates (all cases but one); but
once it represents the number of right rotates (1-9, scan line case 6).
Sometimes I understand the first byte mask, but sometimes (1-7, scan line case
4) it seems reversed from how I would expect it.

Is there other documentation I can review that gives more examples or explains
this in more detail.  Is there a chance that the documentation I'm reading has
some typos?

I particularly do not understand figure 1-9, scan line case 6, which seems to
rotate in an extra pair of bits 3 and 4.


ANSWER:
There seems to be documentation errors as you have correctly pointed.  We will
be fixing them.  Meanwhile, you could refer to -
ddkx86\src\pmdisp\egafam\egavga\comment.blt . The bitblt source is bitblt.asm
and is also located in the same directory.




!OTHER__________________________________**********
June 05, 1995
QUESTION: (Ref: HI7)
I have a network driver and an application that uses this driver.  The
application (client-server) allocates a memory buffer to transmit/receive
operations and passes it to the driver.  The driver locks this memory and
performs network operations.  Sometimes OS/2 totally hangs if the driver has
locked the memory with the SHORT TERM attribute but OS/2 never hangs when I
use the LONG TERM memory lock attribute.  What is the difference between LONG
and SHORT term locking and why would it cause OS/2 to hang in my case?


ANSWER:
1. If you are using the DevHlp_Lock call in a 32-bit OS like OS/2 2.X, this
call is very expensive in terms of resource and performance.  If your network
device driver is supporting 16-bit applications, then for this devhelp to work
properly in OS/2 2.X, the OS should make physical memory below 16MB and mark
it fixed.  Use the VMLock devhelp instead, if you do not need to support
16-bit applications.

2. Short term locks are locks which will be applied by the DD for LESS THAN 2
SECONDS on a memory object.  The memory object should be unlocked before 2
seconds else the consequences will be unpredictable.  If you feel that the
memory has to be locked for a longer duration, apply the long term lock on the
memory object.

In short term locks the memory object is fixed at its current physical address
whereas in the case of long term locks it is moved to regions reserved for
fixed segments.

3. You can cause OS/2 to hang if you use short term locks for longer periods
of time ( > 2 seconds).  It will cause an adequate amount of movable,
swappable memory from being available for system use and for memory allocation
for other applications within the system.

Ref: PDD ref, remarks  section of "DevHlp_Lock"




!OTHER__________________________________**********
June 05, 1995
QUESTION: (Ref. HI3)
I am using Developer Connection DDK Version 2 to make SVGA.EXE.  The
"makefile" in SVGAUTIL directory uses "lib\clibcer.lib", but "clibcer.lib" is
missing, previous version of this makefile was using "slibcer.lib", which is
no longer available in Version 2.

What is the difference between the two and where do I get a copy of
"clibcer.lib"?


ANSWER:
The earlier versions were built on the Small Memory Model (Code & Data limited
to 64K) - the /AS option.  SVGAUTIL on DDK 2 is built on the Compact Model -
the /AC option (Code is limited to 64K) When you write mixed model
programs,you are responsible for determining which library (if any) is
suitable for your program and for ensuring that the appropriate library is
linked.The following shows the libraries from which to extract the start-up
routine for each customised memory model -

Memory Model Option                  StartUp Routine from Library
/AS                                                SLIBCER.LIB
/AC                                                CLIBCER.LIB

The library is packaged along with Microsoft C v6.0




!OTHER__________________________________**********
June 02, 1995
QUESTION: (Ref. HI0)
1. In Windows their is an API call to the keyboard driver to simulate a key
press to the system.  Is their a similar call in OS/2?  If so, what are the
details.  If not, how can I simulate key presses to the system?

2. The device driver will require options to be entered on the device=xxx line
in the config.sys file.  How do I read these parameters, or how are they
passed to me during init?


ANSWER:
1. You can pass the keystroke to the keyboard DD thru the IDC interface of the
device independent keyboard driver (KBDBASE.SYS).  To get the address of the
IDC interface of the device independent keyboard driver, you could issue
DevHlp_AttachDD call.  The name of the device independent keyboard driver is
KBD$.  Insert the scancode by calling the IDC function Process_Keystroke.
Ref:  You could refer to the following sources in the directory:

ddkx86\src\dev\kbd\ibmkbd\kbdinit.c, function - Init - attaches to device
independent keyboard driver

ddkx86\src\dev\kbd\ibmkbd\kbdstate.c, function - SendPacket - inserts a
keystroke into the device independent keyboard driver.

ddkx86\src\dev\kbd\kbdbase\kbdidc.asm, procedure - KbdIDC - IDC entry from
other device dependent drivers

I/O device driver reference, Chapter on "keyboard Device Driver" and "Keyboard
Interdevice driver interface"

2. In the INIT request packet at offset 18 (ie.  [ES:BX]+18) gives the address
of the command line arguments.  Ref :  'Writing OS/2 2.1 Device Drivers in C",
Steve J. Mastrianni Appendix - C, Refer to following Listings -

a. Standard OS/2 device driver include file, structure ReqPacket
b. Device Driver for Memory Mapped Adapters - ISA bus setup

In the same book also refer to Chapter 8,Figure 8-1 ISA & Microchannel INIT
Section , the Device Initialisation Routine.




!STORAGE________________________________**********
June 05, 1995
QUESTION:  (Ref: HH3)
I would like to modify the Atapi driver.  In doing so, I would like to put in
different fixed values for the port addresses.  It seems to me that now the
base port address is retrieved in the claim unit function by making a call to
issue_resource report, then stuffing the value returned for the start port
into the adapter table.  I would like to circumvent this and stuff in my own
value for the address but I am wary of the consequences since I do not know
why the address and IRQ are retrieved in this way or how these values are
presently determined.

Q1. Why is the address retrieved in this way?

A1. Refer to RMBASE.ZIP regarding an introduction to Resource Manager
    architecture and concepts.  The Resource Manager documentation,
    RMBASE.ZIP, is available on the DUDE BBS in the MAIN file area.  The
    Resource Manager keeps track of the shared resources and the owners of
    these resources.  The shared resources could be Interrupt channels, DMA
    channels, I/O addr etc...

    The ATAPI driver utilizes the resource manager to acquire resources needed
    by the device driver during its initialization i.e.  I/O and IRQs which
    are free and available on the given system.
==============================================================================

Q2. How is the address determined?

A2. The driver determines the port address and IRQ via the command line
    parameters specified in the given config.sys and then reserves them using
    Resource Manager calls.
==============================================================================

Q3. Will circumventing this have any disastrous effects?

A3. By circumventing, the problem would be contention with other drivers
    claiming the same resources as your driver.  Also, it is better to conform
    to this architecture to allow for future migration of your driver.




!OTHER__________________________________**********
June 05, 1995
QUESTION: (Ref: HF3)
What is the minimum level of Resource Management Functionality required by a
device driver to be classified as "RM AWARE" ???  Basically what RMLIB calls
are needed ( for example an ADD driver ). RMCreateAdapter / RMAllocateResource
...Etc\


ANSWER:
A driver is said to be RM aware if it uses at least the following Resource
Management services provided by the RM -

RMCreateDriver
RMDestroyDriver
RMCreateAdapter
RMDestroyAdapter
RMAllocResource
RMDeallocResource




!STORAGE________________________________**********
June 05, 1995
QUESTION: (Ref: HE8)
Is there any way to know the drive letter where my CD-ROM drive installed?


ANSWER:
To find out the drive letter where your CDROM drive is installed, try the
following code -

#define CDType            0x8000
#define FirstDrive             0
#define Binary_to_Printable 0x41
#define LastDrive             26

// used for CD number of units Ioctl
struct {
        USHORT count;
        USHORT first;
        } cdinfo;

// array of device info to be collected
BIOSPARAMETERBLOCK devices[LastDrive];

ULONG Action;
HFILE handle;
ULONG datasize;
UCHAR DriveIndex=1;

// check for CD drives
  if(!DosOpen("\\DEV\\CD-ROM2$",&handle,&Action,0,
             FILE_NORMAL,OPEN_ACTION_OPEN_IF_EXISTS,
             OPEN_SHARE_DENYNONE|OPEN_ACCESS_READONLY,
             NULL))
    {
    datasize=sizeof(cdinfo);
    if(!(rc=DosDevIOCtl(handle,0x82,0x60,
      NULL, 0, NULL,(PVOID)&cdinfo,
      sizeof(cdinfo), &datasize)))
      {
      // mark those devices as CDs
      while(cdinfo.count--)
        {
        devices[cdinfo.first+cdinfo.count].fsDeviceAttr|=CDType;
        // say its a CD device
        } /* end while */
      } /* end if */
    DosClose(handle);
    } /* end if */

for(DriveIndex=FirstDrive; DriveIndex<LastDrive; DriveIndex++)
    {
    if(devices[DriveIndex].bDeviceType)
      {
      printf("Device %c is ", DriveIndex+Binary_to_Printable);
      if(devices[DriveIndex].fsDeviceAttr & CDType)
        {
        printf("a  CDROM drive");
        }
      printf("\n");
      } /* end if */
    } /* end for */




!OTHER__________________________________**********
June 05, 1995
QUESTION: (Ref: HD7)
We manufacture a Sound Blaster Pro compatible Sound Card for the PS/2 (Micro
Channel) machines.  We have sold many thousands of these cards to happy PS/2
owners.  However a Dark Cloud has arisen on the OS/2 front.

How do we debug a Windows driver in the WIN-OS/2 environemnt?  I am used to
using the Windows Debug Kernal and a Serial Port connection.


ANSWER:
You will need the OS/2 Debug Kernel,which should be at the same level as the
Retail Version.  The Debug Terminal is Hooked upto the Machine Under Test
through the Serial Port.  Just make sure that the Symbol file name is the same
as the Driver name with the .SYM extension and is in the same directory as the
driver itself (in Windows, you could specify the Symbol file directory)




!OTHER__________________________________**********
JUN 06, 1995
QUESTION:  (Ref: HD6)
Q1. Is it possible and legal to hook my VDD on several software interrupts?
    In other words, call VDHInstallIntHook several times for several interrupt
    vectors and pass different handlers to them.

A1. It is possible to call VDHInstallIntHook several times in order to hook
    different interrupts and pass them to different handlers.
==============================================================================

Q2. Can I pass one handler for several interrupts?

A2. The same handler can be specified for several interrupts.  If you need to
    know which software interrupt has caused the invocation of the handler,
    you could pass the information to the handler as an additional parameter.
==============================================================================

Q3. On OS/2, I have the network driver that implements the socket interface
    for the LAT protocol.  Now I need to write the VDD for this driver but the
    issue is that my customer has two kinds of applications that talk in
    DOS/WINDOWS sessions with this protocol.

    One of the applications uses the new protocol via INTXX and the other uses
    the old protocol interface via INTYY.  I have the following alternatives:

      - Write one VDD with two interrupt handlers (for INTXX and for
         INTYY+MAPPER)

      - Write two VDDs that hook on the correspondent interrupt and
         communicates with the OS/2 PDD.

    Which is the better solution and why?

A3. I suggest writing one VDD to handle INTxx and translate the INTYY in the
    same VDD.  Less code = less maintenance and fewer bugs to fix.

    You can have one VDD with two interrupt handlers.  You can refer to
    ddkx86\src\vdev\vcom directory where the same VDD handles COMn.  This is
    implemented by port trapping.  In your case it will be via interrupts.
