This is file: 08_94QA.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)
==============================================================================

!STORAGE________________________________**********
August 31, 1994
QUESTION: (Ref: none)
1. Does OS/2's emulation of DOS CDROM support open/read access to a CDROM/XA
   Mode 2 format?  (A developer says he uses a 2FH function 1510H in DOS to
   access the CDROM (a Video CD, XA format) drive thru DOS MSCDEX.

2.Is OS/2's MSCDEX emulation version 2.2 or 2.3 compatible?  The old docs say
  it's MSCDEX version 2.1 compatible.


ANSWER:
The VCDROM.SYS device driver supports MSCDEX version 2.21 in the OS/2 2.1,
2.11 and Warp products.  This support includes support for int 2FH function
1510H.  As far as read commands from the DOS application, if it is
DOS_READ_LONG or any IOCtl commands, then we support it.




!STORAGE________________________________**********
August 31, 1994
QUESTION: (Ref: F06)
I'm working on my FSD and have a question.  I'm trying to detect if a new
IFS_OPENCREATE is for a file that is already open.  I believe that I read
somewhere that the sffsi passed in is a per instance item and thus is unique
even if iti~ it is for an already open file.  Idxxx Is the sfi_selfsfn field
of the sffsi the same for all instances of the same file?  If not, is there an
item somewhere that will identify the file without having to parse the
path+filename?


ANSWER:
I don't think there is anyway for the IFS to GET info that is for an already
opened file.  You could SAVE info and compare, but the two instances are
unique.




!STORAGE________________________________**********
August 31, 1994
QUESTION: (Ref: E02)
I'm writing a split-level IFS where a daemon process is interfacing with the
IFS via FS_FSCtl.  My question falls into the area of semaphores.

My plan, so far, would be generally as follows:  At daemon initialization, the
daemon creates several event and mutex semaphores, then passes these handles
into the FSD through FS_FSCtl.

The daemon process sends a few threads into the FSD and each waits on a
specific event.  As an app thread enters the FSD (at FS_OPENCREATE, for
example) it obtains a mutex, fills the daemon thread's 'threadstore' buffer and
posts the event that the daemon thread is waiting on.  The daemon thread, just
awakened, would then release the mutex, enabling the next FS_OPENCREATE thread
to proceed.

I have read in 'The Design of OS/2' how one thread can access a system
semaphore only if it's process has 'opened' it, thus 'sharing' ownership.

1. Does this still hold within system space?

2. That is, can an application thread, from within an FSD interact with
   semaphores created by another process and passed in via FS_FSCtl?

3. If not, how can an FSD effectively use semaphores without expecting
   applications to 'open' some set of semaphores?

4. If a second process attempts to open a file that is already opened by
   another process, is it the FSD that checks access rights, or is a second
   request for a file opened with deny_readwrite denied by the system without
   FSD action?

5. Is it the FSD or system that returns the file handle to the application?
   If the FSD, what is it?

6. In the DevHelp library, can an FSD use VMalloc, VMSetMem allocate & manage
   a cache memory.  (Do these functions REALLY cause a page to be placed in
   physical memory immediately?  or are these not as I believe them to be?)

7. Is ownership of semaphores still required while running in system space?
   (ie can an app thread use semaphores created by a daemon process that
   passes the handles in through FS_FSCtl?  If not, Is there some other way to
   coordinate threads so that an app thread may pass data to/from these daemon
   threads?

8. I know that the address of the DevHelp entry point is passed in at FS_INIT
   time.  I save the address but how do I choose a particular function when I
   call the entry point?  (in c).


ANSWER:
For questions 1,2,3 the daemon need not do ANY semaphores at all, these can
all be done in the FSD as it saves much work.  A ULONG field can be used as a
RAM semaphore, and if you use the FSH_SemRequest/FSH_SemClear function for the
'mutex' then you have the serialization.  There are no 'event' semaphores, in
kernel mode,so you use the Block and Run Devhelps.  My split level IFS does
Daemon calls into FSD, and Blocks.  Client request comes in, FSH_SemRequest to
serialize, do setup work (lock buffers, convert to physical addresses) then
does a Run on the Daemon thread, and a Block on itself.  The daemon thread
awakens, does the setup work (Devhelp PhysToUVirt to give the daemon access to
the callers buffers) and returns to the daemon, process, call back into the
FSD, Run the client thread, then Block itself again..  Client thread awakens,
does cleanup work (unlock memory), deserialize, and return to caller.  repeat
adnauseum.

4.  The sharing is checked in the file system router above the FSD

5.  The file system router above the FSD returns the handle.

6.  An FSD can use these functions to manage a cache, and yes the memory
    could be immediately backed by real memory if the correct options are
    selected or FSH_SegAlloc...

7.  See answer previously (1,2,3) (but Yes, one must Open the semaphore before
    accessing it, even in kernel mode.

8.  You use the DevHelp C functions supplied on the DDK in the \src\dev\dasd\
    devhelp directory, and in the DHCALLS.LIB built from the makefile there.  OR
    you write your OWN masm interfaces, as the DevHelp interfaces are register
    not stack oriented.




!OTHER__________________________________**********
August 25, 1994
QUESTION: (Ref: E38)
The only development system C compiler my group has is IBM C Set ++.  Is there
any reason why we cannot use this product to develop our driver provided, of
course, all linkages are _Far16 _Pascal and we construct an appropriate C
function call library to the DevHlp service routines?


ANSWER:
Based on the information you provided in your message, I gather you are
writing a 16-bit device driver.  In your case, IBM C Set ++ is not the
compiler to use because it is ONLY a 32-bit compiler.

MS 6.0 compiler was used for the 16-bit parallel device driver sample code on
the DDK.  Other 16-bit compilers are IBM C/2, Watcom C16, & Borland 3.5.




!OTHER__________________________________**********
August 25, 1994
QUESTION: (Ref: E35)
I have written a VDD that does not have a PDD.  How can the VDD display a
message during Init phase, showing version number, etc?  My code has a Printf
statement.  The message, however, appears on the Debug terminal only, if using
the Debug version of the kernel.  Use of "sprintf" causes errors at the link
stage.  Alternatively, can the version information be displayed thru the
Syslevel command?


ANSWER:
Use the DosPutMessage API - this sends a message to an output file or device.

   char Message Y" = "Hello World";
   DosPutMessage(1,strlen(Message),Message);

These instructions print the message on the STDOUT.  For further details refer
to the OS/2 Control Programming Reference.




!OTHER__________________________________**********
August 25, 1994
QUESTION: (Ref: E20)
We are having trouble with NMI traps occuring when we try to set breakpoints
in our hardware interrupt handler.  It looks like the PS/2 watchdog timer is
kicking in an causing the NMI.

We are using ASDT (as we have since OS/2 1.1 days) to debug.  I know I've used
ASDT to step through interrupt handlers in the past.  It seems like something
has changed recently.  In any case, has anyone run into this kind of problem
before and figured out a way around it.  Is there any way to tell OS/2 2.x to
forget using the watchdog timer on PS/2's?


ANSWER:
The WatchDog Timer can be disabled by Setting Bit 4 of the System Control Port
A (hex 0092) to 0 using the BIOS Interface.  Further details could be looked
into in the PS/2 Hardware Interface Technical Reference Manual-Section on
System Timers.




!BASE !STORAGE__________________________**********
August 25, 1994
QUESTION: (Ref: E15)
I need your help with regards to SCSI ADD driver initialization and PCI BIOS
calls.  I am currently enhancing my company's SCSI ADD driver to support the
PCI BIOS Application Programming Interface.

Q1. What is the plan for OS/2 2.x to provide support for PCI.  Are there
    additional commands available to take care of PCI dependent information ?

A1. The plan for OS/2 2.x to provide support for PCI has to be clarified by
    the OS/2 Development team.
==============================================================================

Q2. I would like to issue ROM BIOS CALL during ADD initialization.  I would
    like to find out what is the best way to do it.  One way I think is
    through the OEMHELP services, but I am not so sure If I can call these
    services during ADD initialization.  The OEMHLP interface sounds like the
    mechanism I need.  I have questions though with regards to integrating
    OEMHLP calls in my ADD device driver.

A2. For making ROM BIOS calls switching modes between protected and real is
    not the recommended way of doing.  There is no explicit reference as to
    use OEMHELP services for making ROMBIOS calls.

    The best way of issuing ROM BIOS calls during ADD Initialization is through
    OEMHLP Services.Protect-mode Applications and PDDs can't access BIOS
    through INT Interface.  OEMHLP Services provide support for making IOCtl
    calls to query various Adapter configuration and ROM BIOS information
    (Refer "Writing OS/2 2.1 Device Drivers in C" Second Edition,Appendix D
    for details).
==============================================================================

Q3. Does the OEMHLP device driver gets installed before all BASEDEV device
    drivers (i.e.  All ADD drivers)?

A3. The OEMHLP driver could be installed before all the BASEDEV device
    drivers.
==============================================================================

Q4. During initialization, I get the DEVHLP entry point from the
    Initialization Request Packet.  Is this a similar mechanism with OEMHLP ?

A4. The Interface to OEMHLP is not through an entry point as in DEVHLP.  These
    functions are basically IOCtl Calls with Category & Function Codes
    specifying the desired Call.
==============================================================================

Q5. In the book "Writing OS/2 2/1 Device Drivers in C (Appendix D)", the
    function call DosOpen is used to open OEMHLP$, DosDevIOCtl is used to get
    ROM BIOS Information and DosClose to close the OEMHLP$ file handle.
    Presently, my ADD is in Assembly.  Do I need special libraries to resolve
    DosOpen, DosDevIOCtl, and DosClose ?  Or, I need to include these function
    calls in my "DEF" files as EXTRN functions ?

    Another way, I am thinking of is to switch to real mode during
    initialization and issue the ROM BIOS interrupt call directly and switch
    back to protected mode when done.

    The ADD driver prefers to go through OS/2 to get PCI configuration
    information rather than accessing the hardware port directly.

A5. The libraries you require will depend on your Development Platform.  If
    you are using Microsoft C Compiler v6.0 ,OS2.LIB contains all the System
    Calls you will require for the OEMHLP IOCtl Call.  You could call the C -
    API from your Assembly Routine taking proper precautions about the Calling
    Convention.  You could also call OEMHLP services through an Assembly
    Interface.  You could browse through the source code in
    \ddk\src\dev\atcom\ateisai.asm in DDKv1.2.  Basically you have to have the
    relevant Include Files & the Relevant Library as in the Code referred to
    above.




!OTHER__________________________________**********
August 25, 1994
QUESTION: (Ref: E13)
My company is making a PCMCIA host controller chip.  I would like to know if
there is any PCMCIA support built in OS/2?

Since our chip is nor Intel 365SL or Databook compatibility, I'd really like
to know if we need to write our own socket services driver?

We currently have a DOS version socket services which works well with Award's
Cardware 2.0 and SystemSoft's CardSoft 3.1.  Is their any information
available as far as how to write a socket services to support our own host
controller?


ANSWER:
WARP beta contains many kinds of socket services for PCMCIA.  For OS/2 2.1 and
2.11 the customer can get the PCMCIA drivers package as follows:

      1) The IBM National Support Center BBS = 919-517-0001
          Look in Library 17 for Device Drivers.. The file was
          added 07/27 and is called OS2PCM.ZIP
          The file description says "OS/2 2.1x PCMCIA Socket
          Service.

      2) CompuServe = Follow the following selection sequence:
         * Computers
         * Software Forms
         * IBM Corporation
         * Technical Service and Support
         * IBM OS/2 Forms
         * IBM OS/2 Support Forum
         * Files icon
         * Library Section: IBM Files (SUP)
         * OS/2 2.1 and 2.11 PCMCIA Support
            File name = OS2PCM.ZIP
                 Size = 313972
                 Date = 07/28/94


Here is the list of chip sets and machine types that OS/2 supports in regards
to PCMCIA:

      System/Chip Set
      ---------------------
      Toshiba/Toshiba
      Zenith/Intel
      AST/Intel
      Compaq/Cirrus Logic
      NCR/Intel
      NEC C/Intel
      NEC E/Cirrus Logic
      IBM TP350&500/Intel
      IBM TP720/IBM Stinger
      IBM TP750/IBM Tomcat
      Ambra/Databook
      Compuadd/Databook
      Panasonic/Cirrus Logic
      Zeos/Intel(?not sure?)

For the documentation of socket service, please look at the chapter called
"PCMCIA Architecture" in the DDK I/O Device Driver Reference.  Current DDK
does not include sample code of the socket services driver, though we're
looking at it being included in the future.




!BASE___________________________________**********
August 25, 1994
QUESTION: (Ref: E04)
From all appearances, I believe that my driver loads.  I have traced the
operation of the initialization routine and it seems to do what it it required
to do.  However, when I try to open the driver using DosOpen I get a return
code of 110 ERROR_OPEN_FAILED.  When I look this error message up in the
reference manual it says that the open failed because of an explicit fail
command.  It does not appear that any of my driver code is being executed
because I have an "INT 3" command as the first instruction in my stragegy
routine and a break is not happening at the KDB terminal.

I don't know if this is related but I am not sure what to do about all the
information that the driver wants about units, etc.  I am writing a device
driver for an Analog-to-Digital Converter.  Since I will be using DMA, for
data transfer, I believe that this falls under the classification of a block
device.  But I keep field which need to be filled in because IBM interprets
block device as a Disk Drive.

Going back to the original problem.  In the device header, I set the device
attributes to 0080h.  Is there some way to list all of the devices the system
recognizes?


ANSWER:
The answers to the best of what could be gathered from the questions are:

1. The ERROR_OPEN_FAILED occurs possibly because of incorrect flags
(ulOpenFlag parameter of DosOpen).  If OPEN_ACTION_FAIL _IF_EXISTS is used,
the call will fail if the file already exists.

2. Even character device drivers may use DMA for buffering data and
transfering it in one shot to or from the device.  A block device driver is
required only if a large amount of data is to be passed between the
application and the device.  In the ADC driver if a block DD is required then
Bit 13 of the attribute has to be set to 0 (Non IBM format).

3. The device chain can be traversed by using the following kernel debugger
command :

    .d dev nuldev

and then chaining through the next driver field.  Try using oemdev as a
starting driver for additional drivers




!NETWORK________________________________**********
August 25, 1994
QUESTION: (Ref: E01)
I have questions regarding IBM token ring adapters.  We are developing NDIS mac
drivers for several IBM token ring devices to support a network monitoring tool
we have developed.  The questions are as follows:

Q1. The device level programming interface for the IBM Token-Ring Network 16/4
    Adapter II as documented in SD21-0052-00 seems to indicate that this
    adapter can function in "promiscuous mode", i.e.  that it can copy frames
    not specifically addressed to the adapter, without setting the frame
    copied bit.  For example, there are bits in the RECEIVE CSTAT word that
    indicate whether there was an address match or not for the received frame.

    Can this adapter be programmed to operate in "promiscuous mode", and if
    so, are any undocumented techniques or open bits required to do so?

A1. No, the IBM Token-Ring Network 16/4 Adapter II cannot be programmed to
    operate in promiscuous mode.  The item raised about the RECEIVE CSTAT word
    is a generic architectural provision in the data structures to support
    applications like bridging and promiscuous copy.  However, the microcode
    on the 16/4 Adapter II does not implement actual programming support for
    either.
==============================================================================

Q2. Is the programming interface for the LanStreamer token ring adapters
    essentially the same as for the 16/4 Adapter II ?  Will an NDIS mac driver
    written to the programming interface for the 16/4 Adapter II successfully
    operate a LanStreamer ?  If not, where can programming information
    regarding the LanStreamer be obtained?  Other ISVs have been able to
    obtain this information.

A2. The 16/4 Adapter II and LANStreamer adapters have very different
    programming interfaces.  A device driver written for the 16/4 Adapter II
    will not work with the LANStreamer family of adapters.  If you are
    interested in obtaining programming information for the LANStreamer family
    of adapters, please contact the DDSC team.  Obtaining this information
    will require entering into some sort of contractual agreement with IBM NS
    (such as a bilateral CDA, etc).
==============================================================================

Q3. The TAP (Trace and Performance) adapter operates according to the
    programming interface documented for the shared ram ("Tropic") adapters,
    but the mechanism to put the card into various trace modes is not
    documented in the Lan Technical Reference (SC30-3383-03).  Where can
    programming information regarding this adapter be obtained?  Again, other
    ISVs have been given this information.

A3. There is a manual that contains the programming information for the TAP
    adapter and can be given to IHVs.  I am sending you a copy.  Anyone else
    wishing a copy should contact the DDSC team.




!STORAGE________________________________**********
August 25, 1994
QUESTION: (Ref: D47)
We are in the process of releasing a Parallel/SCSI Converter ADD device
driver.  There is an issue regarding the multiple DMD's trying to allocate the
units controlled by one adapter.  We know the /DM or !DM or /SM or !SM will
enable/disable OS2DASD.DMD and OS2SCSI.DMD to control the devices.  What about
the OS2CDROM and OS2ASPI.DMD?  Also, how do we mix the usage of /DM, !DM, /SM,
!SM for individual units?


ANSWER:
Look at the XXXinit.c code and this will tell you what parameters to use.  The
init routine is called when the Base Device driver in the config.sys is
started.  So if the init c code is looking for a certain parameter, it will be
in the init code.




!OTHER__________________________________**********
August 17, 1994
QUESTION: (Ref: E18)
Q1. I have downloaded and read through all the Q&A's from November '93 through
    July '94.  As I understand it, when building an OS/2 driver, MASM 5.1
    works, MASM 6.0 works but is more difficult, and MASM 6.11 doesn't work at
    all.  I have MASM 6.0 and got MASM 5.1 with the DDK.

    Would someone explain WHAT the differences really are between the versions
    as they relate to OS/2 drivers?  What do I have to do to get MASM 6.0 to
    work?  A similar situation exists with compilers.  I have Visual C/C++ 1.5
    Professional and Watcom C/C++ 10.0.  Some people have reported success
    with Watcom 9.5, but I haven't gotten 10.0 to work.  Watcom support claims
    that no-one at Watcom has ever created a device driver with their 10.0
    compiler, but one of the compiler options is "Physical Device Driver" for
    OS/2.  Heard anything about this?

A1. Please look under "Using DDK" ICON for MASM 6.0 installation.  Keep in
    mind that MASM 5.1, shipped with DDK, also may be used.  Anything after
    MASM 6.0B is not compatible with OS/2.

    MSC 6.0 is a 16 bit compiler which can be used to write OS/2 physical
    device drivers however, it is no longer in production.  MSC 7.0 is not
    compatible with OS/2.

    Please download WATCOM.TXT, it explains that Watcom 9.5 is known to work
    in building OS/2 device drivers.  Concerning Watcom 10.0, we have no
    knowledge of this compiler.  However, Watcom claims that there is no
    difference between it and 9.5 and should work.  Please call Watcom Support
    at 1-800-265-4555 or their BBS at 519-884-2103 for further information.
==============================================================================

Q2. Where can I find reference information about writing ADD's and DMD's?  I
    have the DDK 1.2 and the on-line Book Collection.

A2. See Storage Reference on DDK for this information.
==============================================================================

Q3. Where can I find reference information about writing IFS's?

A3. Download files IFS.ZIP and IFSSRC.ZIP from the DUDE Main File area.
==============================================================================




!BASE !OTHER____________________________**********
August 17, 1994
QUESTION: (Ref: E14)
I am looking through the PCMCIA fax\modem client driver on the DDK, and I see
a piece of code that uses a hardcoded far pointer to reference physical
memory.

The memory in question is part of the BIOS data area which is located at 40:0
on a DOS system.  The OS/2 driver code loads at ULONG with 0x00400000 and
directly dereferences it without doing any sort of Physical-to-linear or
Physical-to-gdt-selector conversion.

My question:  Is there an automatically tiled 0040 GDT selector that
references the 0040 physical segment?  If 0040 is a tiled GDT selector, is
there any place where this is documented?


ANSWER:
Yes, the address 0040 is an automatically tiled GDT selector.  Refer to the
book "The Design of OS/2" by Deitel & Kogan, Page 289 for information
regarding this.




!BASE !STORAGE__________________________**********
August 17, 1994
QUESTION: (Ref: E08)
We are hacking your sample floppy driver to handle some emulation that we must
do for our device.  We need to write and read from a particular place in
memory that is shadowed.  To unshadow it in the DOS Environment we have
written to two ports using outp().  Can I do it the same way in OS/2?

How do I need to do the memory accesses.  I need to access physical address
0x000e0000 - 0x000e8000.  Is there an easy way to accomplish this?


ANSWER:
Input/Output and access to physical address can be done in a driver.  Refer to
Steve Mastrianni's book on Writing OS/2 2.1 Device Drivers pages 164 to 171
for details.  Essentially, INIT can do i/o.  The physical addresses have to be
mapped to User Virtual address space by the driver and the virtual pointer is
passed to the application If the physical address is to be accessed from the
Interrupt routine then a selector from GDT should be allocated and used.




!BASE___________________________________**********
August 17, 1994
QUESTION: (Ref: E07)
Q1. Can I build a device driver with the C Set ++ 2.1 (32-bit only) without
    any use of 16-bit code/compiler?

A1. Depends on what kind of device driver you need; while you can build a
    presentation driver (like a printer driver or the PM part of a display
    driver) using a 32-bit compiler (C Set++ or CL386, which ships with the
    DDK), you will need a 16-bit compiler for a physical device driver because
    OS/2 PDD's still use 16-bit architecture.  A third kind of drivers, the
    Virtual device drivers, can also be 32-bit.
==============================================================================

Q2. Are there any limitations to this approach?

A2. Assuming that the question applies to only drivers that can be built in
    32-bit, it is recommended that OS/2 Presentation drivers and virtual
    device drivers be built in 32-bit only.
==============================================================================

Q3. Is the 16:16 memory model used at all within the device driver?  If so,
    what issues should I be aware of?

A3. See answer to # 1
==============================================================================

Q4. Will a 32-bit device driver be constantly thunking into 16-bit code?

A4. A Presentation driver goes through 32-bit GRE, 32-bit GPI and now, 32-bit
    PM; so it has minimal thunking.
==============================================================================

Q5. Do I require any IBM toolkit besides the OS/2 Developer's Toolkit, in
    order to write a device driver?  In other words, with only the Dev
    Toolkit, can I access the DevHelps (C library) and all device driver
    functions that are necessary?

A5. You would require the Pen Toolkit if you were developing Pen for OS/2
    drivers; but otherwise, all the source code required to build a device
    driver is available in the DDK.  You will also need any compilers and/or
    assemblers that might be required to build your particular driver, if they
    are not shipped along with the DDK.
==============================================================================

Q6. Why would one want to purchase the Device Driver Source Kit?

A6. The DDK provides real, tested, working OS/2 device drivers source code, in
    addition to sample code.  This large amount of source code provides a
    ready template which greatly helps in the device driver development
    effort.  Development cycle will be reduced considerably as a result of
    using the DDK.

    The DDK comes with a number of tools, some compilers and assemblers that
    can be used in driver development.

    The DDK also contains a lot of online documentation regarding device
    drivers and pointers to more references.

    The DDK can be Ordered at 1-(800) 633-8266 :  The part number is #
    71G3703.




!I/O____________________________________**********
August 17, 1994
QUESTION: (Ref: E03)
In implementing the port contention API under OS/2 2.11, I have a couple of
questions:

Q1. Is there a way for a PDD to detect during initialzation that an installed
parallel port has the "Share Access" feature enabled?

Q2. Since our driver talks to the parallel port using the physical I/O
address, how do I map a physical I/O address to the logical port number
required by the port contention API?

The physical address relates to the I/O address associated with a given
parallel port.  The I/O address is the means from which communications is
performed.  On an IBM system, the typical I/O addresses associated with
parallel ports are 0x3BC, 0x378, and 0x278.  These addresses are normally
stored in the BIOS Communications Data Area (0x0000:0x0408) during the boot
sequence.  Since our driver communicates with the parallel port using the
physical I/O address, and the port contention handler uses logical port
numbers (i.e.  LPT1) we need to know what logical port number (LPTn) is
associated with a given parallel port's I/O address.


ANSWER:
A1. There does not seem to be any direct way to get at this setting from the
INIT routine but the following trick may be useful:

Call Request Exclusive Access (ref.  I/O D REF page 174) twice.  If it
succeeds both times it means that the Share access is enabled.  Remember to
release the lock afterwards.

A2. The port numbers are arrived in the order in which they are listed in BIOS
data area.  The first parallel port would be LPT1 (index 0) and the next
parallel port would be LPT2 and so on.  The same indexing scheme would apply
for serial ports too (COM1, COM2 etc.)




!STORAGE________________________________**********
August 17, 1994
QUESTION: (Ref: D92)
I need an OS/2 PDD (*.sys) for a HP DAT drive.  Has anybody written such a
driver?


ANSWER:
At this time, IBM has no OS/2 device drivers for tape drives.  There are tape
hardware devices which are supported under OS/2 by third parties.  The
following information on HP DAT drives was obtained from the OS/2 Hardware
Compatibility List (see PCMTABLE.ZIP in Main file area of DUDE bbs):

 Model#                        Software Support
--------                    ------------------

35470A 4mm DAT       Sytos Plus for OS/2, NovaBack for OS/2,
(Jet Store 2000)     Conner Backup Exec Ver 3.1, PCX Backup
                     Wiz, ARCsolo for OS/2, Fastback Plus for OS/2

35480 4mm DAT        Sytos Plus for OS/2, NovaBack for OS/2,
(Jet Store 2000)     Conner Backup Exec Ver 3.1, PCX Backup
                     Wiz, ARCsolo for OS/2, Fastback Plus for OS/2


In addtion, here are some vendor phone #'s:

ADPI          800-758-1041  One For All
Cheyenne   516-484-5110  ARCsolo for OS/2
Conner       800-222-5871  Backup Exec for OS/2
MSR           409-564-1862  Backmaster
NovaSto     818-707-9900  Novaback
PCX           619-259-9797  Backup Wiz
Sytron        508-898-0100  Sytos Plus
Symantec    503-465-8420  Fastback Plus for OS/2




!BASE___________________________________**********
August 12, 1994
QUESTION: (Ref: D97)
1) What is the latest debug kernel for OS/2 2.1 (or latest DDK cd)

2) I know the OS/2 docs say the # of block devices (logical drives) is limited
to 26 but is there a undocumented way to have more than 26 logical drives ?


ANSWER:
1) The kernel debugger version is dependant on what level you are at.  You
state you want the latest 2.1 kernel debugger.  Is that with or with out the
service pack and or the fix pack?

  CSD LEVEL          BUILD LEVEL
  (SYSLEVEL)         (TRAP INFO)                       KNOWN AS
  ----------         -----------           --------------------------------
   XR02000              6.307              2.0 GA
   XR02000              6.427              2.00.1 Pre-load
   XR02010              6.454              2.00.1 Pre-load Backup Diskettes
   XR06055              6.466              2.0 + Service Pack 1
   XR02010              6.514              2.1 GA
   XR06100              6.543              2.0 + Service Pack 2
   XR02110              6.599              S3 Video Debug
   XR06200              6.617              2.1 + Service Pack
|  XR06200              6.617            * 2.1 + Service Pack + BRKLPK CSD Fix
   XR06200              6.617              2.11 (MR-1)
   XR02011              6.618              OS/2 For Windows
   XR06300              6.629              OS/2 For Windows + Service Pack

* Available on DUDE as KDBBRKLP.ZIP. Customer MUST know if he has CSD fix pack
on as CSD LEVEL and BUILD LEVEL are the SAME as without the fix pack. However,
the kernals require different debuggers.


2) 26 is the logical drive limit, it has to be one Alphabetical character.




!MULTIMEDIA_____________________________**********
August 12, 1994
QUESTION: (Ref: D96)
I have ONE question about Pointers.

Let us take an example : Category 80h IOCTL, function 44h : AUDIO_LOAD
                         struct audio_load
                         {
                          char far * pbuffer ;
                          ...
When OS/2 sound manager calls the audio PDD, pbuffer is a 16:16 pointer.  When
our CSet/2 application calls the audio PDD, pbuffer is a flat 32bit pointer.

I know how to convert a flat 32 bit to 16:16 address, but I don't know who
calls the PDD, and whether I need to convert!

Who should convert flat 32bit adresse into 16:16 - application or audio PDD?
If audio PPD:  HOW CAN the PDD KNOW if pbuffer is a 32 or 16:16 pointer?


ANSWER:
DosDevIOCTL is a standard OS/2 API.  It existed in OS/2 1.x as a 16 bit API
and exists in OS/2 2.x as a 32-bit API.  Both are supported on OS/2 2.x for
compatibilty with 16-bit code.

Device drivers are 16-bit entities.  The addresses fed to device drivers for
IOCTL requests are 16:16 addresses - regardless of the bitness of the calling
application.

The OS/2 API service code and ultimately the kernel are responsible for
routing IOCTL requests from applications (16 and 32 bit) to device drivers.

* The 32-bit flat addresses are thunked to 16-bit equivalents.

The 32-bit IOCTL call also includes some new parameters - device drivers can
change the size of the passed buffer.

To support these newer format IOCTL packets, device drivers must tell the
kernel that they support them - via bit in capabilities header.

The "normal" bug when coding DosDevIOCTL is failing to
   #define INCL_DOSDEVICES
   #include <os2.h>

The toolkit (OS/2 2.0 level) has this #define wrong in the sample.




!STORAGE________________________________**********
August 12, 1994
QUESTION: (Ref: D80)
I'm writing a file system driver for CD Recorders which does not support EAs
at all.  In order to allow the user to access the file system with the
Workplace Shell I'm not returning ERROR_NOT_SUPPORTED, but an empty EA buffer.
Writing EAs is simply ignored.

This works fine with the OS/2 1.3 PMFILE application, but the OS/2 2.x Drive
object shows an empty folder.  I can't seem to find the reason for this
behaviour.....

The request sequence of the Drive object is similar to the following:

- open a file named "A.+,;=[].B" to check support for special characters
  (rejected)
- do a FINDFIRST Level 1 with max. 3 matches (O.K.)
- do a FINDFIRST Level 3 with the name of 3rd directory found above (O.K.)
- open or create a file named "WP ROOT. SF" (rejected)
- do a FINDFIRST Level 3 for the complete root directory (O.K.)
- show an empty drive folder
               -----------------------------------

Q1. What is the extact layout of FINDFIRST/FINDNEXT Level 3 information?  The
    CP References for 1.x and 2.x differ on this aspect, neither telling
    anything reliable.

A1. In general, for file system structures, use the 1.3 CP references.  Since
    the file systems are still 16 bit, they are still using the structures
    that were defined for the OS/2 16 bit version.  The kernel does the
    conversion to the 32 bit structure.  I am painfully aware that the IFS doc
    needs to be expanded and should not be referencing the CP reference, but I
    am afraid I do not know when that work will be done.  In any case here is
    an example of the find level 3 structure:

 typedef struct _FEALIST {       /* feal */
     ULONG  cbList;              /* total bytes of structure inc full list */
     FEA    list[1];          /* variable length FEA structures */
  }
 /* A Full EA (FEA) is the complete name/value pair. The header of the */
 /* FEA is defined as the bytes containing the Reserved, cbName and    */
 /* cbValue fields.                                                    */
 /*                                                                    */
 /* NOTE The name field length is dependent on the value in the cbName */
 /*      field and can vary from FEA to FEA. The value field should    */
 /*      cbValue.                                                      */

 typedef struct _fEA
 {
    BYTE   fEA;             /* bit flag describing the characteristics */
                            /*  of the EA. Bit 15 is the only bit that */
                            /*  is not reserved (always 0). Bit 15,    */
                            /*  critical EA.                           */
    BYTE   cbName;          /* EA name length, excluding the NULL      */
    U16    cbValue;         /* length of the EA value                  */
    unsigned char name[1];  /* Variable length ASCIIZ name             */
 } fEA;

 /*  FindFirst/Next level 3 (find record, EAs that match the GEAList,  */
 /*                          cbName and Name)                          */

  struct find_3{

    unsigned short  dateCreate;   /* file creation date                 */
    unsigned short  timeCreate;   /* file creation time                 */
    unsigned short  dateAccess;   /* last date accessed                 */
    unsigned short  timeAccess;   /* last time accessed                 */
    unsigned short  dateWrite;    /* last date updated                  */
    unsigned short  timeWrite;    /* last time updated                  */
    long cbEOF;                   /* file size                          */
    long cbAlloc;                 /* file allocation size               */
    unsigned short attr;          /* file attributes                    */
                                  /* Variable _FEALIST goes here        */
                                  /* cbName goes after the EA list      */
                                  /* szName is the end.                 */
  };

 In your case since you never have EAs, your structure would be:

  struct find_3{

    unsigned short  dateCreate;   /* file creation date                 */
    unsigned short  timeCreate;   /* file creation time                 */
    unsigned short  dateAccess;   /* last date accessed                 */
    unsigned short  timeAccess;   /* last time accessed                 */
    unsigned short  dateWrite;    /* last date updated                  */
    unsigned short  timeWrite;    /* last time updated                  */
    long cbEOF;                   /* file size                          */
    long cbAlloc;                 /* file allocation size               */
    unsigned short attr;          /* file attributes                    */
    ULONG cblist;                 /* length of fealist, always set to 4 */
                                  /*  for an empty list.                */
    unsigned char cbName;         /* length of file name                */
    unsigned char szName;         /* file name                          */
==============================================================================

Q2. What happens if multiple entries are requested in a single Level 3
    FINDFIRST/FINDNEXT request?  Especially important is the search position
    field which is used by FINDFROMNAME.

A2. I am not sure what you mean by multiple entries- multiple files or
    multiple EAs?  If you mean that they are requesting that multiple files be
    returned, the find entries are returned one after another in the buffer up
    to the buffer size or match count.  If you mean multiple EAs in the EA
    list, you can still return an fealist with just a single ULONG entry set
    to 4. This is the architected requirement.

    When you are asked for position information, a ULONG is added to the
    beginning of the find structure.  This information can be requested for
    any level of find.  You can use this field any way you wish.  The
    requirement is that if the contents of this field and the file name that
    was in the same structure is passed in to you in a findfromname request,
    you can restart (aka resync or rewind) the search back to the file that
    follows this file.  Most of the time, the file name passed in is the last
    file you passed back, but it is possible that it could be any file you
    have returned since the first search request.
==============================================================================

Q3. Where are the EAs for each file entry?  When requesting Level 3
    information from a CD-ROM drive (which certainly has to deal with the same
    things), the EAOP structure in the result buffer remains unchanged and
    Level 2 information (cbList == 4 -- an empty FEALIST?)  is appended to the
    EAOP field.

    This, in turn, differs from both CP References which claim that a Level 1
    structure is inserted somewhere in the result buffer.  Neither tells where
    this Level 1 information can be found, though.

A3. See answer to first question.  The FEAList is put after attr and before
    cbName.
==============================================================================

Q4. What do I have to return to signal that no EAs are available?

A4. The cblist field in the FEAList is set to 4.
==============================================================================

Q5. I understand that OS/2 has to perform some remapping of the data buffers
    from 32-Bit applications (because file systems are 16-Bit), but what
    exactly is OS/2 doing?

A5. It is remapping the 1.3 style 16 bit structures to the new 32 style.  It
    will also iteratively call the IFS if the user's request is too big for
    the 32 bit interface.




!MULTIMEDIA_____________________________**********
August 12, 1994
QUESTION: (Ref: D75)
Technical question about developing a MMPM/2 audio physical device driver on a
specific hardware, and specific data ( MPEG instead of Wave ).

We are developing a MMPM/2 Audio PDD.  This driver will manage fully the IDC
interface with an Audio Stream Handler Device Driver (SHDD).

1) Do we need to develop the Audio Stream Handler Device Driver (SHDD)?  IF
not:  (a SHDD exist and can be used)

2) Where can we find this Audio SHDD (is ADSHDD.SYS ok)?
3) Do we need to install the Audio SHDD somewhere?
4) Do we need to add lines in config.sys?
5) How can we specify new data types?
6) How does application call the SHDD?

We call SpiCreateStream() in our application, but it returns an error 9 and
the PDD is not called via DDCMDEntryPoint!

ANSWER:
1) No, your audio DD will communicate with ADSHDD.SYS (audio stream handler).
2) ADSHDD.SYS is shipped within the MMPM/2 subsystem, source code is NOT
   provided.
3) ADSHDD gets installed during normal MMPM/2 install time (via MINSTALL).
4) No, MINSTALL does it for you.
5) All datatypes that are supported are typedef'ed in the MMSYSTEM.H file.
   The audio device driver is told of the datatype during stream creation.
   This info is retieved from MMIO and the appropriate I/O Proc.
6) An application NEVER calls a stream handler, only the Sync Stream Manager
   (SSM) and audio/video device drivers communicate with stream handlers.
   An application either issues MCI calls or more low level SPI calls.

  Your call to SpiCreateStream() is probably passing a NULL pointer.
  Things to check:
    - the pointer to the SPCB
    - src/tgt stream handler ids
    - pointer to DCB
    - pointer to EVCB

You can look at the PMADDE.EXE program for specific coding.


FOLLOW-UP QUESTION:
We still have not managed to access our audio PDD via SSM (and SHD).

Using PMADDE (audio device driver exerciser 1.0 )
   1) we have the following error: Unable to load Device Specific info 87
   2) In menu OPTION, Change Device shows nothing !! (no device to select)
      However, we have our audio PDD in the config.sys.
      (with 16 devices, Strategy(), and DDCMD() implemented).
      (and all our IOCTL call are ok : DosDevIoctl()... )

PROBLEM: calling SpiCreateStream()
   3) We still have error N9, with no NULL pointer in SPCB,DCB,EVCB, SHDids.
      And the PDD DDCMDEntryPoint() is not called.
      Find hereafter the calling sequence, if at first glance you can see
      something wrong.


FOLLOW_UP ANSWER:
Assuming problem #(3) is also using PMADDE, then all three problems are
related.  Your device driver is not being recongized by PMADDE, because PMADDE
has been changed to query the MMPM.INI file (via MCI) to get all device names
installed.  I used to have a /D:devicename switch on the excuting command line
to override any device name that you wanted to test.  The DDK guys
accidentially removed this switch.

Anyway, what you will need to do is edit the mmpm2.ini file to reflect a
correct installation of your adapter/driver.  If you do it by hand, be
careful!  Otherwise, use MINSTALL (with appropriate ctrl files) to install
your device.




!BASE___________________________________**********
August 18, 1994
QUESTION: (Ref: D67)
Is there a "standard" way for a (Physical Device Driver) PDD to retrieve
configuration data.  Right now I am using an ASCII text file that contains the
configuration data that is used during initialzation.


ANSWER:
Standard way is to put the configuration into CONFI.SYS and get the argument
with INIT strategy command.

Please refer to 0h-INIT command of PDD Strategy Command chapter in Physical
Device Driver Reference.




!OTHER__________________________________**********
August 12, 1994
QUESTION: (Ref: D63)
In my physical device driver, I am occasionally getting an error return code
of 1 from the DevHelp call LockSeg.  I am requesting long term, any memory,
and block until available.  This error seems to only occure during its first
attempt.  This leads me to believe that this error is occuring during a page
fault (I believe OS/2 2.1 uses demand paging).  One thing interesting is that
immediatly prior to the LockSeg failure, DevHlp VerifyAccess succeeds.

Can anyone tell me what this LockSeg return code of 1 means?  Return codes are
not documented for LockSeg in the IBM device driver manuals, nor in Steve
Mastrianni's book.


ANSWER:
We do not have any Devhelp function called LockSeg.  I believe you must be
using Steve Mastrianni' book.  Please verify this.

In his library, OS/2 PDD DevHlp_Lock function calls LockSeg.  Unfortunately I
do not know his source code of DevHlp library.  I'm not sure what return code
"1" means.  But the you can get the real return code from OS2KRNL as follows:

On kernel debugger, at the place where is going to call LockSeg function, just
step into through LockSeg code.  You may find the following ASM code:

     MOV   DL,  DevHlp_Lock            ; setting Lokc function code
     CALL  Device_Help               ; calling Devfunction entry point

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

The control will return from DevHelp function.  Like "Physical Device Driver
Reference" says, if your DevHelp function fails, you will get Carry flag on,
and the value of AX will be real error code.  if devhelp function success,
Carry is off.  The definition of the error code are defined in DDK\H\BSEERR.H.




!BASE___________________________________**********
August 12, 1994
QUESTION: (Ref: D54)
I am currently trying to write a Physical Device Driver for an A/D converter
card (Amplicon PC26AT).

I am having problems in implementing the interrupt processing.  The interrupt
processing should be started on a receipt of a READ request packet.

    The A/D converter handles up to 16 channels. On receipt of the
    READ packet I do the following

    1. CHECK THAT THE DEVICE HAS BEEN OPENED

    2. SET UP THE RECIEVE QUEUE SIZE

    3. CONFIGURE THE A/D FOR INTERRUPT SAMPLING.

    4. BLOCK UNTIL THE THREAD IS UNBLOCKED IN THE INTERRUPT HANDLER.

The problem that I am encountering is that the thread is never unblocked, I
think this is because the interrupt handler is never being enterred.

I have checked my functions which interface to the A/D card in a DOS test
harness.  Using this test harness and the A/D modules, the A/D issues
interrupts successfully.

I have followed the instructions in Steven Mastrianni's 'Writing OS/2 2.0
Device Drivers in 'C'.  The host PC is an ISA bus machine.

The device is installed as follows:
    DEVICE=C:\...\PC26AT.SYS IRQ=3 MEM=0320

My 'Blocking' code was taken straight out of one of Steven J. Mastrianni's
Writing OS/2 2.0 Device Drivers in 'C'.

Also how can I get a copy of the Physical Device Drivers Reference Manual.


ANSWER:
Please refer to "Physical Device Driver Reference", DevHlp_ProbBlock, there is
sample code there.  You will find out the difference between Steve's book and
IBM PDD manual.  Most of device drivers code in OS/2 have some condition, for
example checking the job is done, with while statement and DevHlp_ProcBlock in
there.  It is one possiblity that you can try.  But this is based on the
assumption that your interrupt routine gets control and issue DevHlp_ProcRun.

So make sure that your interrupt routine gets control when you set the break
point at your interrupt routine and interrupt happens.  And also make sure
that your Event ID for ProcRun matches to Event ID from ProcBlock.  To order a
hard copy of the reference manuals, call 1-800-426-7282.




!OTHER !STORAGE_________________________**********
August 12, 1994
QUESTION: (Ref: D50)
We are trying to get OS/2 to run with our systems.  The time table to get this
to work is very short.  I decided to try and use the OS/2 interrupt 13 device
driver.  This driver is used to allow OS/2 to use the BIOS to talk to the disk
subsystem instead of a specific device driver.  Our BIOS in our system
supports mirrored disks, caching, system auditing....  When I activate this
device driver (removing the buslogic device driver) OS/2 will use the BIOS and
all functions (except the caching) work.  The caching is not required at this
time.

The main problem is none of our utilities that run under DOS work.  Our
utilities send a command to the BIOS via a write (or read) to a special
location on disk (DISK LABEL).  When this is done the BIOS will parse out the
buffer that is passed to extract any special commands (down disk, revive
disks, disk status...)  This all works under DOS and WINDOWS it does not
workunder OS/2.

OS/2 on a read from this location will not move the protected mode buffer to
the BIOS buffer, thus no command is passed.  On a write an illegal operation
is returned (these reads and writes are outside of the DOS partition or HPFS).

I need to get the source for this device driver so we can modify the driver to
allow these special commands to pass thru.  If this is not possible is there
some other way to handle this.


ANSWER:
The passing of an INT 13 request from a utility running in a DOS VDM is a
function of VDSK.SYS, not the IBMINT13 driver.

VDSK converts the DOS VDM Int 13 read requests to OS/2 IOCTLs.  These requests
are converted to IORBs by OS2DASD.DMD and passed to the .ADD drivers.  DOS VDM
Int 13 write requests to fixed disks are blocked by VDSK.SYS

IOCTL read requests that are out of range would normally be blocked by
OS2DASD.DMD.

If the OEM is issuing INT 13 read/write requests to a specific disk location
to control their BIOS, both OS2DASD.DMD and VDSK.SYS would need to be
modified.

I believe all of this source code is included in the DDK.

I should note that, we do not recommend or endorse this approach.  The Int 13
driver was not designed for high-performance applications.  We recommend that
you port your BIOS implementations to the appropriate OS/2 protect mode
drivers.




!OTHER__________________________________**********
August 12, 1994
QUESTION: (Ref: D43)
I've just been doing some experiments with the BRn kernel debug command to set
386/486 hardware breakpoints, this definitely used to work under 1.X but no
matter what I do under 2.X I cannot get get it to work.  Can you shed some
light on this - or am I doing something dumb.


ANSWER:
As far as your question is worded, I'm assuming you want to break when a DOS
app accesses the BIOS data area, be aware that DOS apps in 2.x VDM's don't use
this particular selector, they use a ring 3 alias linear address to the BIOS
data area (&40:xx is translated).  Keep in mind that when you set the
breakpoint, you need to be in the context of the VDM (to break on the correct
linear address).


FOLLOW-UP QUESTION:
I do understand the OS/2 memory architecture & I did supply the correct linear
address for the bios data area.  I patched the DR6 & DR0-3 registers manually
with the correct settings & tried the BR debug commands & then within the same
protected mode session (not a VDM) tried accessing the LINEAR address upon
which I'd set the hardware - nothing happened.  I used this particular
sequence in the OS/2 Internals Course for 1.3, that I wrote & delivered for
the IBM developers at Hursley, it worked then why not now?

The customers actual requirement (the above is my test case) is to breakpoint
on a write to the A000:0 physical address.  So if you could ask the developers
if they can get the BR command to work, & by work, I mean get it to do
anything at all, I'd be grateful.  My suspicion is either this is no longer
possible under OS/2 2.X or I'm doing something really dumb.


FOLLOW_UP ANSWER:
BREAKPOINT (BR)

o BR[<bp>] E|W|R|1|2|4 [<addr>] [<passcnt>] ["<bp cmds>"]

This command sets an 80386 debug register.  Debug registers can be used to
break on data reads and writes, and instruction execution (which is the same
as a regular breakpoint).  Up to four debug registers can be set and enabled
at one time.  Disabled BR breakpoints do not use up a debug register.  The
flag definitions are:

Flag   Description

1      One-byte length (default)
2      Word length on a word boundary
4      Doubleword length on a doubleword boundary
E      Break on instruction execution only (one-byte length only)
W      Break on writes only
R      Break on reads and writes

For one-byte breakpoints, the linear address alignment does not matter, but
for word-length breakpoints the linear address must be on a word boundary.
For a doubleword-length breakpoint, the linear address must be on a doubleword
boundary.  The debugger converts the address to linear, and prints an error
message if the alignment is incorrect.

Only addresses that can be converted to linear (segment, selector, and linear,
but not physical) can be used in the BR command address.  The rest of the
arguments are exactly like a BP command.

...Setting a Data Breakpoint

ulReturn = int3call(0x100, "This is Lab 1A");
printf ("The value returned was %8X \n", ulReturn);
internalcall (ulReturn);
internalcallstatic (ulReturn);
exit(0);

static VOID internalcallstatic (ULONG ulValue)
     {
     if (ulValue == 0x76543210) ulGlobalvar = 10;
     }




!OTHER__________________________________**********
August 12, 1994
QUESTION: (Ref: D39)
I have been using the InfoROM test suite to test our ADD and am observing some
errors.

1. Are there guidelines for determining the cause of the errors?  I ran the
same tests on a host adapter supported by an ADD included with OS/2 2.11
distribution and it failed much the same way.

2. Is there someplace I can send the results for analysis?

Questions regarding running the test suites:

3. Should the system under test be rebooted between tests?

4. During execution of the tests "TESTASY" and "TESTSY", the operator is
prompted to enter a "UNIT HANDLE".  I've noticed the number that appears next
to the Unit Handle label in the test window changes from time to time.  Is
this normal?  I do make sure I'm looking at the same unit everytime.  The
window isn't quite wide enough to display the unit type without having to
scroll right.  I'm thinking this change in unit handle may have something to
do with question #1.  Also, are the unit handle numbers assigned dynamically
or are they fixed and should be the same for a particular device every time
the test is run?

5. Can the DASD test scripts be run on the boot DASD or should a second DASD
be installed for the test to be run on?  The reason I ask is that TESTSY hangs
the system consistently when executed on the boot drive.

6. Can the DASD or CDROM be at fault for test failures instead of the ADD and
how does one determine if they are at fault if they can be?


ANSWER:
1. There are no guidelines, at present, for interpreting results of the
InfoROM.  Generally, the tests we have taken a closer look at at the ones that
got an "ERROR" string logged to the log file.

Comparing results to an IBM ADD is a good mechanism.  We have discovered in
using this tool there are tests that show problems in APIs/functions that we
can test and see, but nobody uses or cares about.  Without seeing the actual
test that failed, I can't pass judgement on the specific error you are seeing.

Suggestions:
   a) Check with the developer of your driver, do the function(s) under test
      get heavy use?  Are they fully implemented in your Device Driver?

   b) Generally tests that fail in the same way as a similar IBM ADD should be
      of lesser concern, but we would appreciate hearing about them!

2. At this time we do not have a mechanism in place to help you interpret the
results, if your DD writer can't help you, then you can try sending your
results back to me via this mechanism, and I will try.

3. There is no reason to reboot the system under test between tests.  If you
find this is necessary, then there is a problem.  You will to reboot after you
install the test device driver used for DASD ADD (DASDADD.SYS) testing.

4. The Unit Handle returned in the previous call to DD_GETDEVICETABLE must be
typed in when prompted by the test script, DEVTABLE.SY.  This is so because if
the user has multiple drives attached, the device under test must be selected.
The Unit Handle numbers should not change through multiple executions of DDTT,
they are static for a given device.

5. The DASDADD tests can be run on the system drive.  The command files that
control execution of tests, TESTSY.CMD and TESTASY.CMD, have had the write
tests commented out.  I recommend getting another disk to try the write tests.

6. The device could be at fault, again I think your DD writer would be in a
better place to help you make this determination.  Error codes reported by
DDTT for DASDADD errors are usually DD dependent, you might try the IBM
Storage Device Driver Reference or the OS/2 Physical Device Driver Ref.




!BASE___________________________________**********
August 12, 1994
QUESTION: (Ref: D36)
How do I unmap the memory that I have mapped via the PhysToUVirt call?

When a user process closes the device driver I want to make sure that it can
not access the physical memory block any longer, therefore I need to
de-allocate or delete the mapping that I created with the PhysToUVirt call.

In Mastriani's book, it says that UnPhysToVirt "performs no function" in OS/2
2.x.  If so then what Device Help routine should I used to free LDTs which are
mapped by a call to PhysToUVirt?


ANSWER:
The customer can use DevHlp_PhysToUVirt function again to free a selector
return on a prior call to PhysToUVirt.  And the customer needs to specify
request_type = 2 for it.

If the customer take a look at "DevHlp_PhysToUVirt " section in DDK Physical
Device Driver Reference, he/she will find the description about releasing
mapped selector in "Remarks:".




!STORAGE________________________________**********
August 12, 1994
QUESTION: (Ref: D30)
We are currently developing a driver for our IDE controller which functions on
the PS/2 line operating under SCO UNIX.  Our sources at SCO indicated that
their OS looks for drive parameters in the EBDA area at boot time (the IBM
standard for drive parameter passing).  Since with our adapter the MC PS/2
line has no way of getting the parameters of the hard disk connected to our
adapter, 'we' need to fill this area with the appropriate data...hence our
need for this (EBDA) data area's structure and location.  This is especially
necessary for the development of a bootable device.  As a second and/or third
hard disk device these parameters can be passed 'on the fly'.


ANSWER:
The device driver developer appears to need the offset of the Fixed Disk drive
parameter tables (2) in the Extended BIOS Data Area.  He also needs the
starting address of the EBDA.  SCO uses the information from these tables to
determine drive characteristics.  There does not appear to be a need for SCSI
or ESDI information.

The segment address for the EBDA can be obtained from Int 15H AH=C1H.  There
are two fixed disk drive parameter tables in the EBDA at offsets 003DH and
004DH.  Each table is 16 bytes long and is formatted with cylinder, head,
sector parameters for ST-506 drives as specified in the BIOS Tech Ref.
section 4.




!OTHER__________________________________**********
August 12, 1994
QUESTION: (Ref: D06)
I am trying to call DosSetFilePtr from the driver.  I am using OS2286.LIB
provided with the 1.2 DDK, and it appears that this function has been left
out of the library.
Can you verify this and if this true find a solution for me?


ANSWER:
Try to link to OS2386.LIB to use this doscall.  It should work.




!VIDEO__________________________________**********
August 12, 1994
QUESTION: (Ref: C46)
I finally had the time to try this out using TSENG ET400 based video board
running 800x600x256 color.  Problem DOES NOT occur using this board, so it is
not related to APAR PJ06325 as we previously thought.  Something is still
missing in my implementation of palette management, and I'll need some help in
figuring out what it is....

Seamless windows 256 color bitmaps are not being restored correctly after
switching between a 256 color seamless application and a NON 256 COLOR PM
application on the Desktop.

The seamless application that I am running is Windows Paintbrush.  The bitmap
that I selected to be drawn is 256 color, and is drawn correctly.  GPI
SetPalette for the BMP's color palette has been done in the seamless windows
driver, and has updated windows private copy of the palette.

I then move the cursor out of seamless window and click on a PM object
(PMGLOBE) which causes focus to be switched away from Paintbrush.  At this
point, everything is OK.  DAC has not been reprogrammed, so colors for 256
color bitmap in seamless window remain valid.

I then move the cursor into another PM app ( WIN-OS/2 Accessories - Icon
View).  At this time, PM set palette is done for some reason, and the DAC is
programmed (all 256 locations) with a default palette.(???)

    Why was this done? PM Globe is NOT 256 color. It only uses system colors.

At this point, obviously the DAC is no longer valid for the 256 color BMP in
the seamless window.  I would expect that this is all OK so far.....  I really
don't understand PM palette management too well.

NOW, THE PROBLEM...  When I switch back to the seamless window, something
should re-realize the HW palette for the bitmap being displayed.  This is not
happening.  How is this mechanism supposed to work ???

I presumed that maybe the shield would issue another SetPalette, but I
verified that this was not being done by setting a BP in windows driver.  As
far as I can tell, none of the windows GPIs that have anything to do with
palette mmgmt are being sent...

I know how this mechanism works in our Windows 3.1 drivers.  At INT2F switch
to foreground, we know that we are palette enabled, and ASSUME that the DAC is
no longer valid for the current palette.  Therefore, we always restore the DAC
from a local copy of current palette data.  Very simple, doesn't take much
time.

I don't understand how this is supposed to work in OS/2 seamless.  I have no
source code examples of SVGA seamless palette management, and can find nothing
in any documentation as to how this is supposed to work.

;---------------------------------------------------------------------------

As I mentioned above, this problem does not occur on a TSENG ET4000 based
board using currently released OS/2 2.1 drivers.

                SV600256.DLL    ; OS/2 driver
                WSPDSSF.DRV     ; Seamless Windows driver

I can select any application on the desktop, and the palette for the 256 color
bitmap displayed in Windows Paintbrush remains valid.

I used the SVGA256 source code as the base for my PM driver, and has only a
few modifications from that used to build the TSENG driver.  No changes at all
were made in any of the palette management code.  So I have basically ruled
out the PM driver as the source of the problem (???).

I have the following additional questions.

1) My understanding is that the seamless windows driver should NEVER program
the HW Palette ( DAC ) unless GDI SetPalette is sent with a valid lpPalette (
NON VOID ) address.  Is this correct?  If so, my assumption is there is no
place in the windows driver that I should have to restore the HW palette.

2) I'm curious about the use of ulLastPalUpdate in PM/Windows shared data
area.  The online documentation states:  " When the focus changes and the
application now in focus realizes, the entire palette is reshuffled.  This
invalidates the current GDI palette entries.  The time stamp is a mechanism
for the GDI to be instantly aware of this change.  "

So...  is there anything that the seamless windows drivers needs to do with
this field ??  I can see this being used in PALETTE.ASM module in PM driver
source.

When and where is the GDI palette re-realized ??


ANSWER:
Have you implemented PALINIT escapes in Contro()?

If you do not have, this is the information on its implementation.

1) Add this defines & structure member to IPC.INC
SEAMLESS_ESC_PALINIT      equ  6010         ;Pass back address of palette
                                            ;related datas.

 These are the palette management related filds in PMDD_IO (i.e the PM &
 Seamless
 shared area.) :

         bfPaletteIsFixed     db  ?       ; TRUE if palette manager not enabled
         ulLastPalUpdate      dd  ?       ; time stamp of last foreground
                                          ; realize
         pHWPalette           dd  ?       ; 16:16 ptr to HWPalette structure

NOTE:  These three fields must be together and in this sequence in the PMDD_IO
structure.

 2) In Control() add SEAMLESS_ESC_PALINIT, device escape function support.

 This is what you have to do when Control() is called with
 Function=SEAMLESS_ESC_PALINIT

 -----------------------------------------------------------------------
        cmp     seg_lpOutData, 0
        je      ExitControl

        mov     di, seg init_Struct             ; Set DS -> DATA seg.
        mov     ds, di

        mov     di,  PMDD_IO_SEL                ; ES:DI -> Shared area.
        mov     es,  di
        mov     edi, init_Struct.pmdd_io

        ;Thunk the 32bit flat ptr to the first palette datas into ESI:
        ; Mult high word of the flat ptr by 8 and set the LS 3 bits on.
        lea     edi, es:Yedi".bfPaletteIsFixed
        shld    esi, edi, 19
        or      esi, 7
        shl     esi, 16
        mov     si, di
        les     di, lpOutData

         les     di, lpOutData
         mov     dword ptr es:Ydi", esi

         jmp     SM_GoodExit
 -----------------------------------------------------------------------




=================== Administrative Stuff ===================
________________________________________**********
August 25, 1994
