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

!OTHER__________________________________**********
March 30, 1994
QUESTION: (Ref: A60)
ASDT32 will not work on a clone, even after switching to VGA.


ANSWER:
The following patch works w/ ASDT32 1.1 and keyboards on some clone and some
ValuePoint machines.  I don't really know the best way to tell when this patch
should be applied, but end users are welcome to try it when they get keyboard
hangs when ASDT32 is installed.

     find 0x752BB96400E464
     change 0x75 to 0x74

     find 0x50B00AE620EB00
     change 0x50B0 to 0xEB0F




!OTHER__________________________________**********
March 30, 1994
QUESTION: (Ref: A47)
Customer reports having an installation problem.  He gets the error message
EPFIE142 while doing DDK install.  Error always occurs when installing Common
component.  He is running a 486/66 clone, 16MB ram, 250 MB HD, OS/2 2.1, AMI
bios, DDK v1.1, Toshiba SCSI CD-ROM.


ANSWER:
This error code means insufficient disk space.  Customer was trying to install
components totalling approximately 17MB.  He had to free up approximately 50MB
on his hard disk to successfully install.  The extra space was necessary
because of temporary storage used during the install.




!OTHER__________________________________**********
March 30, 1994
QUESTION: (Ref: A42)
We are developing OS/2 display drivers.  Currently our driver is running ok
under English OS/2 2.1.  But under Japanese OS/2 2.1, it has problem
displaying Japanese characters.  I have heard that the driver needs to support
double-byte characters in order to run Japanese OS/2.  If this is true, how
can I modify our driver to be double-byte aware?  Is there any document that I
can follow?


ANSWER:
  Source code for the following DBCS drivers is on DDK v1.2:
      - DBCS Base Video Handler
      - DBCS Base Video Handler for Windowed Session
      - DBCS PM (VGA and SVGA 256)
      - DBCS VGA/SVGA Virtual Video Driver
      - DBCS Base Video Screen
      - DBCS PM Font Support Driver

DDK v1.2 is now available.  If you have a DDK subscription, you should be
receiving your copy within the next week or two.

The Japanese versions of OS/2 and the DDK, as well as the OS/2 DBCS
implementation, are developed and supported by IBM Japan.  If you require more
information on DBCS or on the Japanese version of OS/2 or the Japanese version
of the DDK, you can fax your questions to the Japanese Developers Assistance
Program (DAP) at +81-3-3279-8231.




!MULTIMEDIA_____________________________**********
March 30, 1994
QUESTION: (Ref: A34)
Q1. We found that our audio device driver cannot pass all PCM test script
    files.  I check it and get surprise.  After the audio DD is received the
    AUDIO_INIT message under Category 80H IOCtl and pass back audio initialize
    info.  to MMOS/2, the MMOS/2 send the message to audio PDD again.
    Normally, the message is audio information, i.e the sample rate, number of
    bits per sample etc., but to certain PCM test script, like Wave Audio Play
    8b, 11k, PCM, Stereo, the audio PDD is received the deinitialize the track
    infomation, i.e.  the mode item in audio_init struct is set to IDLE, pls.
    refer to the page 100 at MMPM/2 Device Driver Reference.  I am not sure
    why the audio DD got the deinitialize message from MMOS/2.  Would you like
    to check for me under what condition the MMOS/2 will send the info.  to
    DD.  I attach the test script file to you.

A1. Ini file probably has no stereo support, so that when the INIT comes down
    as 8b, 11k stereo the Ampmixer de-initializes the DD.
------------------------------------------------------------------------------

Q2. When I play MMPM/2 Digital Audio on XXX DDs and open a WAVE file, then
    press record button, the system will respond with an "Internal error 5088,
    Device resource is not available".  All record prodecure flow is the same
    both Open and New options and get the defference result.  Please provide
    me answer why the system respond the prompt and base on what info.  the
    system do it because the system never commnucate with audio DD before
    prompting the message.

A2. "Resource not available" could mean in ini file cannot record for default
    settings (i.e.  16 bit).

    In summary:
    Your ini file is configured for a SB with only 8 bit mono capability.
    Change the ini file to reflect the capabilities of your adapter.  If the
    ini file is correct, then the problem lies in the RESOURCE.DLL.  Here
    again, the DLL should be replaced with your version OR set RCID=?  equal
    to a value that is equivalent to your card.  For example, if your card has
    the same capabilies as PAS16, then RCID=5 in the MMPM2.INI file under
    [Ampmixer].
------------------------------------------------------------------------------

Q3. By the way, have you any Plug and Play function on OS/2 because I shall
    write PNP DD on windows and DOS.  Pls.  inform me if IBM will support the
    PNP.

A3. IBM Personal Software Products (PSP) division demonstrated Plug and Play
    technology running on OS/2 at Fall/COMDEX'93.  We plan to make support for
    Plug and Play available in a future release of the operating system.

    Further information will be available at the OS/2 Device Driver Conference
    being held as part of the IBM Personal Software Products Technical
    Interchange in San Francisco, April 25-29.

    You should be able to order any tapes they record at the conference if are
    unable to attend.




!VIDEO__________________________________**********
March 30,1994
QUESTIONS: (Ref: A32)
Q1. On the DDK, chapter "Seamless Windows Support", section "Sharing Cursor
    Exclusion and Enable/Disable Code", it says that "The seamless windows
    driver calls the PM ExcludeCursor routine when a hardware cursor is in
    use, DisableCursor when a software cursor is in use, and EnableCursor
    whenever the video RSRamSemaphore is cleared and the destination is the
    screen."

    I call the cursor functions according to the above statement.  Now the
    cursor seems to work all right.  But I have two questions.  One is that I
    don't know where can I use the EnableCursor funciton?  Currently in my
    driver, I never call EnableCursor.  Is it a pair of DisableCursor or
    ExcludeCursor that should be called before calling clear_semaphore?  The
    other question is ExcludeCursor function is called in PM driver when
    software cursor is in use according to my study on PM driver.  I don't
    know why it is called when the hardware cursor is in use in seamless
    windows driver.  The PM source file "eddmccrs.c" also says "the
    disable_cursor function is called when outputing to the screen and the
    cursor is software and the exclusion is not needed.  So should I call the
    cursor functions as said by the DDK or should they be called the other way
    around?

A1. This is how the XGA Seamless driver handles the cursor routines.  After
    the Seamless driver successfully acquired the semaphore If (Screen is
    involved) call ExcludeCursor Else if ( the cursor is a software cursor )
    call DisableCursor.

    Now if either ExcludeCursor or DisableCursor has been called, call
    EnableCursor before the semaphore is being released.

    I hope this will answer the questions you have about cursor routines.
------------------------------------------------------------------------------

Q2. I am not very sure about two sub-functions of device Escapes() from Win
    shield and GDI to seamless windows driver.  They are SEAMLESS_ESC_REQSEM
    and SEAMLESS_ESC_CLRSEM.  Their functions are to obtain/clear the
    FSRamSemaphore on behalf of Win Shield.  But I don't know how to implement
    them.

A2. What you do for the two semaphore escapes is to request and clear
    semaphore in the respective escape.  Note that you do have to call
    DisableCursor/ EnableCursor when the cursor is software cursor.
------------------------------------------------------------------------------

Q3. Some applications have black interior when I run them.  For example the
    interior of Clock and NotePad are totally black.  Could you give me any
    suggestion about this problem?

A3. I am not sure whether you mean the background of the Clock/Notepade or the
    whole client window?  If some of the Seamless apps work well except the
    Clock/Notepade the 1st place I will look are the drawing routines involved
    like Output() or ExtTextOut().




!OTHER__________________________________**********
March 30, 1994
QUESTION: (Ref: A06)
I am developing a PCMCIA client driver.  The PDD driver while incomplete
works.  I have elected to use generic IOCtl to extract test data from the Card
Services.  My problem is that while my test routine makes the DosDevIOCtl call
with a Category and Function of 80h & 41h respectivly, my device driver
receives 5h and 48h.

My original driver delared an error on an IOCTL that it was not expecting.
When I changed it to return DONE the I got the call that I was expecting.  The
spurious call came after the OPEN and before my test program sent its own
IOCTL.

What should a driver do with a IOCTL that it is not handling?


ANSWER:
The file system sends a Category 5 Function 48h IOCtl to all character device
drivers as part of the DosOpen API processing.  It is part of the OS/2
National Language Support.  This IOCtl is not just for parallel ports although
it is defined under the parallel port IOCtls.  It is used to tell device
drivers to initialize their character devices to a particular code page and
font.  If it does not apply to your device ignore the request and return an
error.  The IOCtl does not affect the open processing.




!STORAGE________________________________**********
March 30, 1994
QUESTION: (Ref: A04)
 1. Is there a limit on number of CD-ROM drives that can be attached to single
    CPU - customer needs to know if we can attach 16 (sixteen !), but we can
    only test with 2 at this time.  Is there a physical limit (number of
    physical devices supported by OS), or logical limit (number of letters
    assigned to devices/partitions), or internal limits in kernel, or some
    other design issues?

 2. Is there a support for magneto-optical or other removable cartridge/disk
    drives outside of LOCKDRV.FLT, which only locks the drive and makes it
    look non-removable after the boot process?


ANSWER:
 1. There is no physical limit on the number of CD-ROM drives that can be
    connected except for the connectors themselves.

 2. OS/2 does not have drivers for MO devices; you have to get the
    drivers from the OEM.  We do not have any source code for an MO driver;
    currently they are being developed by the OEM's involved..




!VIDEO__________________________________**********
March 30, 1994
QUESTION: (Ref: 994)
The GDI calls driver function Enable twice.  Then it calls SetPalette function
with a null pointer.  The it calls Control several times to enumerate the
supported subfunction.  Then it calls Control(SEAMLESS_ESC_PALINIT) to ask for
the pointer.  Then it calls Control several times to enumerate the supported
subfunctions.  Then the system crash.  I have one question in
Control(SEAMLESS_ESC_PALINIT).  The returned data in the argument lpOutData is
a pointer to the start of the palette- related data in the PM and Windows
shared data/code area.  lpOutData is a DWORD.  But the pointer to the start of
the palette-related data in the shared data area is 53:1aea67b1.  It's in
16-bit segment and 32-bit offset format.  Where 53 comed from your answer last
time about the INT 66h question.  I passed the offset 1aea67b1 to lpOutData,
is it correct?  Is it the problem to hang the system?  By the way, where
does the selector 53 come from?


ANSWER:
No, you should not return the 32-bit offset.  You should thunk the 32-bit
offset to a 16:16 address and pass the 16:16 address to lpOutData.  This is
the algorithm to use to thunk a 32-bit flat offset to a 16:16 (sel:off)
address:

        lea     edi, es:[edi].bfPaletteIsFixed       ;Start addr of the pal
                                                     ;data in the shared area.
        shld    esi, edi, 19
        or      esi, 7
        shl     esi, 16
        mov     si, di
        les     di, lpOutData
        mov     dword ptr es:[di], esi

In other words mult high word of the flat offset by 8 and set the 1st 3 bit of
the result on and this will become the segment selector.  Use the low word of
the flat offset as the 16 bit offset.  Together they work as 16:16 address.




!VIDEO__________________________________**********
March 30, 1994
QUESTION: (Ref: 979)
I have the source code of the VGA seamless windows display driver.  I try to
write the XGA seamless windows driver by referencing the VGA source code and
the OS/2 DDK reference.  But now I encounter one bug that exit the seamless
application at the GDI or the OS/2 system code.  I don't know what is wrong in
my code.

If I can have more sample source code such as the ones of some other Windows
accelerator, SVGA, or XGA, it would help me a lot.

I have two more question.  At the end of the my Enable function, I called INT
2Fh to disable all hardware WRITE access until the Winshield enable it.  I
don't know when Winshield will enable it.  Is it when the winshield_callback()
function is called?

But when winshield_callback is called, the call_back address win_callback is
still invalid.  It is because the driver Control function hasn't been called.

It is mentioned in the DDK reference, I should call check_hw_access() function
before I call the request_semaphore() function in SetPalette function.  Should
the desired operation HW_READONLY or HW_READWRITE?

Are these desired hardware operations HW_READONLY, HW_WRITEONLY, and
HW_READWRITE for VRAM access only, or they are for VRAM, XGA memory-mapped
registers, and IO indexed registers?


ANSWER:
In SetPalette you don't have to call Check_HW_Access, only Request_Semaphore
is needed because the screen is not involved.

This the general rule:
Request_Semaphore and hence Clear_Semaphore have to be called whenever the
display adapter h/w is involved.  The Semaphore is in place for serializing
the h/w access between PM and Seamless driver.  So the semaphore request is
needed for all type of display h/w access, IO index registers, memory mapped
registers and of course the VRAM access whether screen or off screen.

Now Check_HW_Access is needed whenever the Seamless function needs to access
screen VRAM be it HW_READONLY or HW_WRITEONLY or HW_READWRITE etc.  For
example BitBlt from Screen to Memory, the display h/w state needed in this
case is only HW_READONLY.

This is what you want to take note for UpdateColors.  The h/w state needed
here is HW_FORCEREADWRITE rather than just a HW_READWRITE as you would think
it should be since we are reading the screen and then writing the screen.

Like Check_HW_Access, the cursor routines that are exported from PM driver via
the share area only need to be called whenever screen is involved because it
is for the purpose of excluding and including the cursor on the screen.




!VIDEO__________________________________**********
March 30, 1994
QUESTION: (Ref: 977)
When I run the seamless windows application, after loading my XGA seamless
windows driver, Windows GDI calls the Enable function in my driver.  It
returns O.K.  Then GDI calls the driver SetPalette function with a null
pointer to update the private image copy of the palette.

In this Setpalette function, I read from the XGA hardware palette to set the
image copy of the palette which is pointer by pHWPalette in the PM and Windows
shared data area when a null pointer is passed to SetPalette function.  After
calling this function, it returns to the system code (seems to be GDI or
OS/2).  Then the seamless application terminate (unloading the symbols of my
driver) when it calls into one function of the system code.

The function is:

      4e7:505     call   dword ptr [di+8]   ;br0

In this function, it calls a lot of function in segment 157.

Because it hasn't called the driver's Control(.., SEAMLESS_PAL_INIT, ...)
function, I don't know how does GDI know the address of the palette-related
entries in the PM/Windows shared data/code area.

I know this problem is not very clear.  It is very difficult for me to debug
because it doesn't exit from my driver code.  Hope you can help me.

Thank you very much.


ANSWER:
You are not doing the right thing for SetPalette().  For SetPalette function
when the pointer to color table is NULL the driver should NOT touch the h/w
palette but if the driver does maintain an internal mirror copy of the h/w
palette you should take the opportunity to refresh the palette table by
reading pHWPalette which has the current content of the h/w palette.

On the other hand when the color table pointer is not NULL, you should update
the h/w palette but of course you should first call RequestSem(), update the
respective slot of the h/w palette, then call ClearSem().

Most of the time the color table pointer is NULL even when the Seamless app is
in the foreground and needs to have its palette set to h/w palette.  The only
time the pointer is not NULL is when the Seamless app is doing palette
animation.




!VIDEO__________________________________**********
March 30, 1994
QUESTION: (Ref: 894)
At the initialization of my XGA seamless windows display driver, I call INT
66h (VWIN_INITIALIZE) in the function called ipc_init() in ipc.asm which is
copied from VGA seamless windows driver source code in the DDK.  I believe
all the arguments passed to ipc_init() are correct.  The returned value of
this function is a data structure called WINDD_INIT which is shown below:
WINDD_INIT struc
        proc_id         dw      0
        thred_id        dw      0
        pfvwin          dd      ?
        pmdd_io         dd      0       ;(out) pointer to pmdd_io structure
WINDD_INIT ends

By comparing the returned WINDD_INIT structure by the VGA seamless windows
driver, I am sure that the first 3 elements of this returned structure are
correct.  But the fouth returned element  pmdd_io is a invalid pointer
(invalid selector).  Could you tell me what is the possible cause that INT 66
returns a wrong pointer.

I copied the data structure SEAMLESSDATA in seamless.h of XGA PM display
driver source code and defined it as pmdd_io.  And I used the XGA PM display
driver that is installed by the OS/2 selective install.


ANSWER:
If the seamless driver developer is using XGA PM driver pmdd_io in WINDD_INIT
return from INT 66h is a 32-bit flat ptr. To use this 32 bit flat ptr, he will
have to load 53h into a segment selector and use the 32-bit flat ptr as offset.
For example if he can use DS:ESI to access that area by setting 53h to DS and
WINDD_INIT.pmdd_io to ESI.




!OTHER !VIDEO___________________________**********
March 30, 1994
QUESTION: (Ref: 893)
Q1. I'm a new DDK user.  I'm going through the usual hair-pulling experiences
    of working with a new DDK.  I've navigated around my way around the DDK
    source tree and managed to build a few things, but I'm baffled.

    What has me stumped is the lack of a "production diskette" build facility.
    I was hoping for a single, elegant makefile or command file that would
    assemble all the various .dll's , *.sys's, *.dsc's, *.dsp and produce a
    diskette that could be used to install the sample drivers.

A1. It wouldn't be too difficult to create a makefile which could build all
    the drivers supplied with the DDK.  We do not include this because it
    would take at least two full days to build the entire DDK.  Also, most
    customers are only interested in one driver and hence would not find any
    use for this.
------------------------------------------------------------------------------

Q2. I'm still shaky on the pieces that make up the S3 driver, which is what I
    want to use as my baseline.  What pieces do I need to add to my config.sys
    to get the S3 driver to run?

    Is this really not specifically addressed in the DDK documentation, or
    have I just been looking in all the wrong places?

A2. You are right about the discrepancy in compiler information for S3
    drivers.  The S3 drivers use Microsoft C 6.0 in addition to MASM and
    CL386.  This has been corrected for the new component PMVIDEO that will
    replace S3 in the new release of the DDK.  As for the customer's question,
    could you refer him to the S3 golden install package that was made
    available in October or November of last year ?  That should clarify his
    questions about how all the drivers fit together in the package.  Also,
    please let him know that an updated version of S3 source code will be
    shipped on the soon to be released DDK Version 1.2.

    The S3 install package can be downloaded from the IBM National Support
    Center BBS.  The file is named S3-16M.DSK.  It is located in directory 36.
    The phone number for the bbs is (919)517-0001.

    The S3 display driver install package which was shipped during November'93
    provides a good example of the files required to install S3 drivers on top
    of OS/2 2.1.  Also, the chapter "Installing and Configuring Display Device
    Drivers" in the Display Device Driver Reference Book explains how to use
    the display install utility (DSPINSTL) provided with OS/2 2.1 to install
    display drivers.  Sample code on how to write sample action routines for
    SVGA drivers is provided under the \ddk\dspinstl directory on the DDK.
------------------------------------------------------------------------------

Q3. Is screen01.sys to be installed as a DEVICE= or a BASEDEV=?

A3. For screen01.sys, you just need to copy the new driver to the \OS2
    directory.  It gets loaded by the kernel by default while booting up.
------------------------------------------------------------------------------

Q4. Is there room on the DKK CD to ship the COMPILED drivers (i.e.  all the
    object code).  This would be of enormous help to poor souls like myself,
    since we could immediately detect (and presumably correct) problems with
    our builds.  Alternatively, if space is a problem, at least some sort of
    checksum database so we could isolate those modules that don't match the
    test builds you folks do before shipping the DDK.

A4. We agree in principle with the customer that we could ship the built
    drivers on the DDK; there definitely is enough space for that on the CD.
    So we will submit this request as a customer requirement to the DDK Team.
------------------------------------------------------------------------------

Q5. As a start, I was thinking of implementing a frame buffer that is memory
    mapped so that my driver code can directly write into this mapped memory
    and then this shows up on the screen, in effect bypassing the acceleration
    hardware.  Is there any source available for something like this?

A5. We suspect that the VGA 32-bit driver draws directly to memory-mapped
    frame buffers.
------------------------------------------------------------------------------

Q6. Do DevHlp functions such as VMAlloc disable caching on the allocated
    pages?  If not, how can we disable it?

A6. The DevHlp function VMAlloc in particular allows you to fix the allocated
    pages in memory, so that the pages never get swapped out, if bit 1 is set
    in the call.  This call is documented in Chapter 17 of the Physical Device
    Driver Reference.
------------------------------------------------------------------------------

Q7. In my previous question I had asked whether VMAlloc disables caching on
    the pages it allocates.  The reply I received talked about disabling
    *paging*, which is a different matter altogether.

    One of the things the i86 memory architecture lets you do is enable and
    disable the memory cache on a per-page basis.  This is crucial to
    memory-mapped devices like our graphics accelerator, since we need to, for
    example, poll status registers while the board completes an operation.  If
    caching is enabled for the page that maps to our board, then our code will
    never see the status register change...

    Since I first posted the question, I have gotten our board up and running,
    so presumably VMAlloc DOES in fact disable caching, but I'd still like to
    be sure.

A7. If the physical storage address is NOT part of the system storage (located
    on an adapter card) then OS/2 disables caching for those affected pages.




!MULTIMEDIA_____________________________**********
March 30, 1994
QUESTION: (Ref: 878)
I have completed a virtual device driver for our sound card.  During the
virtual device driver development I found following problems on WIN/DOS
sessions.

Q1. I installed our Windows Sound Systems device driver created from Microsoft
    Windows Sound Systems V2.0 beta DDK on WIN-OS/2.  Under our OS/2 virtual
    device driver the wave functions and mixer functions in the Windows device
    driver work properly.  However the FM synthesis functions work improperly
    as the tempo click is too slow.  I encounter the same problem on DOS
    session if I play a DOS game, i.e.  I can hear the digit sound but cannot
    hear the FM synthesis sound.  I like to check if we can improve this or
    there are any problem in the virtual device driver.

A1. Known limitation.  Timer-0 is virtual to VDMs.  OS/2 timer virtualization
    is 32ms granular.  If you program TIMER.DRV for higher resolution (say
    1ms) then you get 32 interrupts every 32ms.  We are looking into
    impovements.  For each DOS box you should have these settings:

        HW_TIMER                 ON
        INT_DURING_IO            ON
        VIDEO_RETRACE_EMULATION  OFF
------------------------------------------------------------------------------

Q2. I like to prevent access certain port from DOS device driver or WIN-OS/2
    device driver because the IRQ/DMA/Base address in our sound card can be
    changed through writing data to certain port.  I also found that the
    virtual device driver only inhibit access certain port when these port are
    occupied by some applications or DOS/WIN device driver.  Could you provide
    me some advice whenever I can capture certain port access information even
    though there are not any applications or DDs using this.

A2. Generic VDD doesn't provide virtualization.  Re-program DMA/IRQ on close
    from VDD (AUDIOCDM.C).  If you wrote your own VDD, you could virtualize
    the ports.  Recommend users configure DOS/MMPM/WIN for the same DMA/IRQ.
    Here too, we are working on improvemets.  There will be two sessions held
    on this subject at the April '94 San Francisco Device Driver Conference.
------------------------------------------------------------------------------

Q3. We received a requirement from our customers.  They like to a hardware
    SETUP program.  Would you like to check for me if there are any audio
    setup tools in various IBM development kits or provide some idea how to do
    it.

A3. MINSTALL.EXE only.  Editing config.sys is quite common.
------------------------------------------------------------------------------

Q4. So far I found a bug not to be fixed.  When I open WIN-OS/2 session
    meanwhile some OS/2 multimedia applications is running, the virtual device
    driver prompts following message:

        WIN-OS/2 Full Session
        SYS1174:  The XXX161$ device is already in use by another application

    The OS/2 system always halts if I choose the "Retry command or operation"
    option and the OS/2 virtual device driver or physical device driver do not
    receive any message at that time.

A4. DOS driver must give up if the hardware is not present (all IN
    instructions return -1).  If it doesn't die, session will appear hung.




!MULTIMEDIA_____________________________**********
March 30, 1994
QUESTION: (Ref: 832)
Could you give me some advice how to co-ordinate WIN-OS/2 audio device driver
and OS/2 audio PDD?  On the OS/2 system, virtual device driver co-ordinate DOS
driver and OS/2 audio PDD, i.e.  virtual device driver capture certain I/O and
DOS session run on VM86 mode, and we are not sure how to simulate Windows on
OS/2.  We try install Windows audio device driver to WIN-OS/2 and found some
problems that it access certain I/O occupied by OS/2 audio PDD.  Both Windows
audio driver and OS/2 audio PDD are developed by ourself.


ANSWER:
On the DDK in the AUDIOVDD subdirectory there are six *.ASM files that compose
the Audio Virtual devide driver.  You will need to interface to this VDD in
order for you DOS (or Windows) sesssions not to crash MMPM/2.  It is the only
thing that protects it.  Even after you will be done, you will still have only
one DOS/WIN session capable of aceessing the adapter at any time.

Here are the things the author mentioned:

1. Find source of AUDIOVDD (from DDK).  Use only the OS/2 2.1 shipped version.

2. Set PDD Data field to list the adapter's I/O port ranges - see AUDIODAT.C,
   "AdapterInfo".

3. Borrow AUDIOVDM.C from PAS16 sample;
   also open/init/close logic

4. Installation: add name of your PDD to AUDIOVDD.SYS commandline,
   DEVICE=\MMOS2\AUDIOVDD.SYS AZT16.SYS (same name as on IN: param for PDD)

Set AUDIO_ADAPTER_SHARING to "Required"

For the DOS/WIN Audio enabled sessions set:

HW_TIMER                ON
INIT_DURING_IO          ON
VIDEO_RETRACE_EMULATION OFF




!VIDEO__________________________________**********
March 30, 1994
QUESTION: (Ref: 830)
I am writing seamless windows driver for XGA.  I don't know how the PM display
driver coordinate the off-screen VRAM usage with the seamless windows display
driver?  According to the XGA PM display driver source code, PM driver caches
patterns and markers in the off-screen VRAM.  Depending on the available
off-screen VRAM size, it also caches the characters on the off- screen.  And
according to the DDK reference, the off-screen VRAM is statically divided
between PM driver and seamless windows driver.  Could you tell me how does it
statically divided?  Thank you very much.


ANSWER:
"The rules about off screen VRAM coordination betwen PM driver and the windows
driver are defined by the PM driver and the Windows Driver.  Since they both
use it they must not stomp one another".

The customer is advised to look at the display driver source in DDK.  for
example 32 bit PM driver source.  (file EDDEVRAM.C) to get a feel for how the
sharing is done.

Static Division example: 32bit PMVIDEO) driver 8514 case: Basically the bottom
half of the off-screen VRAM is used for font cache. Windows driver and PMDD
share statically as follows.
Windows Driver: bottom 64K.
PMDD: third quadrant of off-screen VRAM.

The customer's best source at this point is the PMDD source.




!OTHER !STORAGE_________________________**********
March 29, 1994
QUESTION: (Ref: A43)
Device driver extensions "BID","VSD","TSD" are described in the Storage Device
Driver Refernce 71G1897.  Can you tell me what these are?


ANSWER:
The extensions .BID .VSD .TSD were going to be used in OS/2 ver 1.2 in the
Ladder drivers.  They are no longer used by OS/2 ver 2.x.




!PRINT__________________________________**********
March 29, 1994
QUESTION: (Ref: A40)
I have located the reason that the MDRIVER sample does not work with
WordPerfect 5.2 for OS2. WP opens the driver as OD_QUEUED PM_Q_RAW. There is
code to handle this in the driver (that is all return codes are good), but
there is no code there to create output for this case.

Do you have an updated driver that handles this case?

If not, do you have guidelines about HOW to generate output in this case ?


ANSWER:
This is a valid concern with the MDriver.

For a workaround:

Printer drivers should set a generate-output flag in two cases under the
DEVESC_STARTDOC case in the function Escape in ESCAPE.C.  Store the
generate-output flag in the DDC structure in DRIVER.H.

1. When the process opens OD_DIRECT.  (ESCAPE.C, line 106)

2. When the process opens OD_QUEUED and datatype PM_Q_RAW.  (ESCAPE.C, line
150)

Both these conditions may be detected in file
\DDK\SRC\PRNTDD\MDRIVER\ESCAPE.C, but it is lacking any code there as your
customer points out.

Then in the DEVESC_ENDDOC and DEVESC_NEWFRAME cases, check the
generate-output flag in the DDC flag instead of the pddc->pdb->ulType flag
as seen on lines 244 and 347 of ESCAPE.C.




!VIDEO__________________________________**********
March 29, 1994
QUESTION: (Ref: 996)
In testing our seamless driver, we have found that color bitmaps tend to crash
Windows when the bitmap is copied via the Clipboard between a seamless session
and WINOS2.  We suspect that the reason for this may be related to the fact
that our full screen Windows driver is palette managed but the PM and Seamless
drivers are not.  We are forced to have the Seamless driver NOT palette
managed because the PM driver isn't palette managed.  When we tried to use a
palette managed Seamless driver, it crashed with weird problems which we were
never able to track down.  We concluded that the seamless driver must behave
the same way as PM due to limitations in VWIN.  It was a big job turning the
Windows driver into a non-managed version, but it would have been harder to
turn PM into a palette managed driver.

The questions are:

1. Is the Clipboard problem a limitation in Windows?

2. Has this issue been addressed by IBM, and has it been tested?

3. And, finally, has OS/2 2.1 seamless support been tested with palette
   managed display drivers, and has it been tested with a mismatch between the
   two?


ANSWER:
1. We are not aware of any such limitation

2. There is a great deal of information pertaining to this subject on our DDK.
   This same information can be found in the Display Device Driver Reference
   Manual.  Please look under the reference for seamless testing in either of
   these sources.  There isn't mucn that we can add to this already existing
   documentation.

   If you do not have our DDK, please look in the INFO file are on the DUDE.
   There are three files you should download and look at:

               DDKANNOU.TXT - original announcement
               DDKORDER.TXT - how to order the DDK
               DDKPRICE.TXT - price reduction

   These same files will tell you how to order the hardcopy reference manual
   if you prefer to go that route.

3. Same as above.  Please see the existing documentation.




!OTHER _________________________________**********
March 25, 1994
QUESTION: (Ref A70)
When calling the DUDE BBS with PMCOMM version 2.0 by multinet, customer was
not seeing the results of his last action taken until he took another action
(i.e.  in the file menu customer types 'd' for download but does not see the
protocol menu until he hits some other key).


ANSWER:
Shutting off the hotkey option from the "C)hange setup menu" (option !)
resulted in the customer being able to use the BBS normally.




!I/O____________________________________**********
March 25, 1994
QUESTION: (Ref: A12)
We have a low level device driver working in other OS's which we wish to port
to OS/2 . To use the same paradigm as elsewhere, we wish to write a PDD which
uses the low-level h/w dependent functionality of the so called "low-level"
PDD.  The inter device driver communication in OS/2 provides only a single
entry point however, and we wish to use quite a number of functions.

Is it possible to use, say an array of functions which starts at the professed
entry point?  That is, is it possible to call entry points placed just below
the professed one, or is it just like calling the strategy routine with a
request packet made up just as the kernel does it?

Is there a standard way of doing this?


ANSWER:
You cannot provide multiple entrypoints via IDC, but YOU define WHAT the IDC
protocol is, so you could proscribe the ES:BX points to a request block, or
AX:BX contains a function code, or push the parms on the stack, or whatever
you determine is appropriate for your situation




!I/O____________________________________**********
March 25, 1994
QUESTION: (Ref: A11)
I am writing a device driver (pdd) for an application written in CSet and
with a buffer declared as struct buf * _Seg16 bufptr; The driver has to
allocate the buffer.

What calls would be necessary?

Is VMAlloc ok, what flag values would be necessary?


ANSWER:
If the pointer is Seg 16, then VMALLOC won't work, but
PhysToUVirt will, this will give a ring 3 selector:offset (16 bit)
pointer to physical memory..




!I/O____________________________________**********
March 25, 1994
QUESTION: (Ref: A02)
We are developing a device driver which requires access to user buffers during
interrupt service.  We are using the following sequence of DevHlp services:

        VMLock
        VMProcessToGlobal...... task level prior to
                                      buffer use
        ....................... use of buffers at interrupt service level
        VMFree................. task level after buffer use is complete
        VMUnlock

Some of our user buffers may be freed within a fraction of a second and others
need to stay locked for many seconds.  Correspondingly, we have sometimes set
bit 4 of the ActionFlags argument to VMLock, and sometimes not.

In the cases where a long-term lock (bit 4 set) has been requested, the
sequence of calls functions as expected.  When a short term lock has been
requested, however, the VMFree call hangs for about ten seconds presumably for
a short term lock timeout; then VMFree returns with a bad parameter indication
(87).

Checks with the kernel debugger show that valid linear addresses are being
passed to VMFree in all cases.  Furthermore, simply setting the long-term lock
bit in all cases makes the problem go away.

If establishing a long term lock is significantly more costly in OS/2
execution time, we cannot, for performance reasons, simply leave long term
locks everywhere.

Do you have any insight into what is happening here?  In another test, we
bypassed locking altogether and VMFree did not hang.  Would it be possible to
reverse the order of VMFree and VMUnlock, or does that confuse the kernel in
other ways?


ANSWER:
The sequence should be:

    VMAlloc
    VMLock
    use
    VMUnlock
    VMFree

    Not
    VMFree
    VMUnlock




!NETWORK________________________________**********
March 25, 1994
QUESTION: (Ref: 991)
How compatible are os/2 1.x and os/2 2.1 drivers?  What I mean is, shouldn't a
driver that works under os/2 1.x also work under 2.1?  I have an NDIS
Conformance Test Tool (MTTOOL) from Microsoft that works under os/2 1.3, but
gets the following error under os/2 2.1:

   A program in this session encountered a problem and connot continue.
   Violation at 0000164F1.  MTTOOL.EXE 0001:f730F37D1.

DWB Associates says mttool is the best tool they know of for ndis testing
and were even disappointed when I told them about it not working under 2.1.

Do you have any ideas?  Shouldn't mttool work under 2.1 if it works under
1.3?  Do you have any suggestions for using any other test tool?


ANSWER:
OS/2 1.3 device drivers should work on OS/2 2.1.  However, I have heard of
some drivers not working correctly.  I do not believe that these
incompatibilities are caused by any NDIS differences.  The two reasons that I
have heard for this incompatibility are:

  - memory management assumptions made by a device driver which
    did not cause a problem on 1.3, but which do cause problems
    on 2.1.

  - use of unpublished 1.3 interfaces or parameters.  These unpublished
    interfaces are not always carried into 2.1.  If this really
     exists in the base, the MTTOOL may have used it, since MTTOOL
    was made by Microsoft.

There is another test tool provided by DWB Associates as a part of the OS/2
NDIS Toolkit.  This should work on OS/2 2.1, and is supported on 2.1 by DWB.

The test driver I am referred to is called the "NDIS Driver Test Tool" or
simply "TestTool".

TestTool is available as part of the "DWB Associates NDIS Device Driver
Toolkit for OS/2 and DOS".  TestTool is described in the documentation as

  "a testing program to exercise an NDIS MAC driver.  It may be used to test
  for NDIS compliance in a stand-alone or networked environment, as well as to
  test for functionality in networked environments."

The toolkit is available from DWB Associates (1800-633-6284).




!NETWORK________________________________**********
March 17, 1994
QUESTION: (Ref: A07)
Can you tell me how I can find the documentation on the locked file device
driver that is used to install LAN and other components.  This seems like a
very useful utility to get around that old locked files problem.


ANSWER:
The Lan Systems folks in Austin inform me that The locked file device driver
is now documented in the ITL redbook "Automated Installation for CID Enabled
ES, LS V3.0 and NTS/2" (GG24-3781).

You can order this pub through the Publication Support Center at 800-879-2755.




!OTHER__________________________________**********
March 17, 1994
QUESTION: (Ref: 986)
I am using Periscope for OS/2 to debug a DLL and am trying to imbed an INT 3
to fire the debugger.  In the BUILTIN.H file from CSET++, there appears to be
a function called _interrupt that would seem to do what I need.  The compile
works fine, but I am unable to find the function in any library at link time.

I have written a small assembly module that generates the INT 3 for me, but it
would be much better if I could put the INTs right where I need them instead
of calling to a function that generates the interrupt.  Any ideas on this?


ANSWER:
_interrupt() is a builtin function and has no backing code in the
library. For the compiler to generate the appropriate Code, the user
must #include <builtin.h> and cannot parathesize _interrupt() function
call, because paranthese specify a call to the "non-existence" backing code.




!OTHER__________________________________**********
March 17, 1994
QUESTION: (Ref: 982)
The pen drivers source code indicates the use  "penei.inc" file.  However,
this file is not included in DDK v1.1.  Nor is it in the Pen toolkit.


ANSWER:
You are not looking at the MAKEFILE correctly.

There is a file in \DDK\SRC\PEN\PENTKT\PENBASE\INC\PENEI.H which is used by
the MAKEFILE via H2INC.EXE to create the above PENEI.INC file.

To fix the problem, read the section on Base Build Structure in the USEDDK.INF
file supplied with the DDK.  The "32bit Pen for OS/2" section explains the
pre-build requirements.

To create the PENEI.INC file, run NMAKE in the \DDK\SRC\PEN\PENTKT\PENBASE\INC
directory BEFORE running NMAKE in the target directory.




!OTHER__________________________________**********
March 17, 1994
QUESTION: (Ref: 973)
1) Is there a protect mode PCMCIA Card Services for OS/2?

2) Did OS/2 follow the "Intel 80286 Protect Mode OS/2" Processor Bindings
found in the PCMCIA SOCKET SERVICES SPECIFICATION Release 2.1, page D-6?

3) Is there a Socket Services/Card Services driver that I need to load?


ANSWER:
1) Yes.  16:16 protect mode

2)  Yes, but the functional support is upto the level 2.0. PCMCIA
specifications.

3)  I did not understand what the customer is trying to do here. But, if he
just looking for PCMCIA drivers, yes, they are in OS/2  PCMCIA.SYS  &
VPCMCIA.SYS.

These drivers should be loaded.




!OTHER__________________________________**********
March 15, 1994
QUESTION: (Ref: A31)
The old Kernel Debugger does not work with the new Service Pack.  Is there a
new Kernel Debugger for the Service Pack?


ANSWER:
There is a new kernel debugger for the recently released Service Pack.
There are two files out in the MAIN FILE area on the DUDE which you need to
download and use with the new Service Pack.

   2_11KDB1.ZIP   (1 of 2)
   2_11KDB2.ZIP   (2 of 2)




!NETWORK________________________________**********
March 15, 1994
QUESTION: (Ref: 989)
I am writing an NDIS driver, and was wondering if there is any way that I can
find out whether I am in kernel mode, interrupt (off the timer), mode,etc.,
when a protocol calls my entry points.

For example, it appears that when NetBEUI calls my TransmitChain function, it
is on a timer interrupt, therefore, I can't block or yield to a blocked
thread.  Other protocols appear to be in kernel mode at that time.

How can I tell, so I know what devhlps I can use?


ANSWER:
No, OS/2 does not provide a method to determine the context mode of a thread.
The very first guideline of the NDIS specification is "All primitives can be
called in either interrupt or task..."  Unfortunately a NDIS MAC driver can't
tell what the mode of the thread is and most of the protocols probably use
interrupt thread most of the time (instead of a IOCTL thread).  So the
inherent design of the MAC driver must consider this and any OS/2 devhelp
services that the driver may need as a result of a NDIS primitive should be
done ahead of time (like during INIT, etc).




!STORAGE________________________________**********
March 15, 1994
QUESTION: (Ref: 966)

After much back and forth struggling with a PDD for our add-on disk drive
products, we were convinced to work on an ADD for our product.  The problems
we were having are related to (1) System locks during file decompression,
corrupted files following file decompression or the inability to run
applications following installation that utilized decompression on an HPFS
partition and (2) to lack of speed (no caching) on both a FAT and HPFS
partition.

The IDE ADD example on the DDK was modified and we seem to be running OK from
a standpoint of the file decompression on an HPFS partition.  We still see no
caching of the drive.

We have been unsuccessful in finding anything in the ADD documentation on
support for caching, or strategy II.

Questions:
1. What is required to achieve caching on an IDE drive?

2. Does your example ADD provide support for caching?

3. Is it necessary to provide any support for strategy 2 in the ADD or is this
   handled by the operating system?

4. Can you direct us to the proper documentation covering these points?


ANSWER:
1 & 2. Disk caching is done in the File system.  Note if you go in to the
   config.sys file you will fine the statement DISKCACHE=512,LW,AC:C this
   statement sets up disk caching The /HCW and /HCD Parameter that is used in
   the ADD driver for R/W enable is spelled out in the Storage Device Ref.
   for Read/Write caching . The Tool kit gives a lot of information on the
   setting up the BASEDEV=xxx driver in the config.sys so the correct
   switches set the correct hardware/software for caching( passing the
   correct parameters).  The tool kit has a lot of information that would be
   too much to try and cover in this note.  I suggest that you look in the
   DDK tool kit for more detail information.

3. Yes, If you read pages 183-185 of Writing Devices Drivers by Steve
   Mastrianni it will tell you all about the Strategy 2 and how it works with
   ADD's drivers.

   The book, "Writing OS/2 2.1 Device Drivers in C", by Steve Mastrianni, is
   available on CompuServe from Compubooks (GO CBK), from Van Nostrand
   Reinhold (800-842-3636), or from IBM (800-879-2755, P/N SR28-4392).  It's
   the only tutorial on writing OS/2 2.x device drivers.

4. The above book can help with your questions.  Also the DDK Storage Device
   Driver Reference Manual, which is also on line in the DDK.




!BASE___________________________________**********
March 15, 1994
QUESTION: (Ref: 965)
I am writing a physical device driver for OS/2 and I have a library of C
functions which facilitates access to the device.  Is it possible to organize
this library as a DLL and call the functions from the PDD at ring 0, or does
the code for the functions have to be permanently resident in memory?


ANSWER:
The difficulties in creating a workable solution using the ring 3 DLL are
numerous.  Technically it could be done, but there are many caveats that
usually make the job impossible, or too difficult to maintain.

An alternate solution might be to have the device driver contain multiple code
segments with the "C functions" located in a SWAPABLE segment.  This will
allow the routines to be swapped to disk if the system becomes constrained.




!I/O____________________________________**********
March 15, 1994
QUESTION: (Ref: 959)
In the mouse PDD source file STRAT.ASM, you have code which detects if the
current strategy call is the first call into the mouse PDD.  If it is, you do
some initialization work (GetDeviceParms, InitSDevice).  The comments state:

     "If this is the 1st level 0 call then we must initialize the
       interface with the device dependent DD. This cannot be done
       at init time because initialization is at level 3 and the
       entry points, returned by AttachDD, to the DDDD are ring 0.
       .."

We are writing a device driver which must do some IDC initialization, which
must be done when we are at ring 0 for the same reason as stated in your code.
Rather than using the mouse.sys approach, will the following approach work:

     - in our driver header, define our driver to be a level 3 driver
     - in our strategy section, do the IDC initialzation upon receipt
       of the 'Init Complete' command

If our approach will not work are there some issues surrounding the STRAT.ASM
approach that we should be aware of?


ANSWER:
We also detect the INIT_COMPLETE command in STRAT.ASM to some ring 0 work.
The dirver header needs to be changed to allow the DD to be caled with that
command.  Use "GREP INITCOMPLETE *.ASM" to where the support needs to be added
and in what context.




!I/O____________________________________**********
March 15, 1994
QUESTION: (Ref: 958)
Q1. Must a device driver that uses interrupts make a (DevHelp)
    RegisterStackUsage() call?

A1. Yes, according to the documentation.  But if you look a the source code
    for MOUSE.SYS, you will seee that it must not be mandatory, since it does
    NOT register.  The reason for registering is to allow the KERNEL to stop
    loading device drivers at INIT time when the planned stack usage is above
    the 8K range.  This, in theory, keeps a device driver from creating a
    system fault due to stack over-run.
==============================================================================

Q2. If a device driver must issue a RegisterStackUsage() call, does it matter
    if that call is made before or after the SetIRQ() call that registers the
    interrupt handler?

A2. It is not documened either way but I would suggest calling the DevHlp
    SETIRQ AFTER the RegisterStackUsage because, if you enable the interrupts
    and subsequently bomb out of init due to overcommitment of the stack by
    other DD's, there is a small window of time hwere the interrupt routinne
    can be called BEFORE you call the DevHlp UNSETIRQ function.
==============================================================================

Q3. What happens if the same (or a different) device driver makes a second
    RegisterStackUsage() call, specifying an interrupt level for which a
    previous RegisterStackUsage() call was successfully made?

A3. Interrupt sharing is allowed for MCA and EISA machines due to the hardware
    architecture but I do not know if the KERNEL checks to see if the current
    machine will allow sharing.  The docs do not say that you CANNOT share
    interrupts on an ISA machine, they just say it is NOT recommended, so my
    guess is that the call will be processed normally.




!STORAGE________________________________**********
March 11, 1994
QUESTION: (Ref: A01)
I was wondering if someone could tell me what the maximum partition size you
can have under OS/2 2.1.  I understand that FAT has a 1023 cylinder
limtitation, but HPFS does not.  We would really like to know the largest
partition IBM tested with, not just the theoretical limit.

Also, if we were talking boot partition what implications would this have?
Would the INT13 support handle it (at least to it's limits) and when a driver
loaded that understood the whole partition then it would be ok?


ANSWER:
The fundamental limits for disk partitions are 2GB for FAT and 64GB for HPFS.
Also the bootable partition on the disk must be within the 1023 partition of
the disk.

For FAT, the absolute limit on partition sizes is 2GB.  This is far beyond the
practical limit.  Cluster sizes start at 2K, and will double every time the
disk space doubles (the first increase happens at the 128Meg partition size).
So, if you have a 1byte file, on a 127M partition, it will take up 2K, on a
129M partition, the same file takes up 4K.

For HPFS, the theoretical limit is 64G per partition.  The main limiting
factor is the time it takes to format, and the ability to run CHKDSK.
Currently, CHKDSK needs about 3bits of RAM for every sector on an HPFS disk -
if your partiition is too big, you might not have enough RAM to run CHKDSK.
Besides, it may take DAYS to run.

I'd say it's best to keep HPFS partitions under 8GB.  Work is currently being
done to improve CHKDSK (no date).




!STORAGE________________________________**********
March 11, 1994
QUESTION: (Ref: 975)
I am developing OS2 ADD driver for our SCSI adapter( non ABIOS), I am confused
by the scatter-gathering data structures in IORB.h (in OS2DDK\DEV\DASD\DISKH)
and IOCC_EXECUTE_IO command:

 /** Scatter/Gather List Entry*/
 typedef struct _SCATGATENTRY  {      /* IOSG */
   ULONG         ppXferBuf;           /* Physical pointer to transfer buffer */
   ULONG         XferBufLen;          /* Length of transfer buffer           */
 } SCATGATENTRY, FAR *PSCATGATENTRY, *NPSCATGATENTRY;
 #define MAXSGLISTSIZE   (sizeof(SCATGATENTRY)) * 16


 /** EXECUTE_IO IORB */                   (for IOCC_EXECUTE_IO)
 typedef struct _IORB_EXECUTEIO  {            /* IOXIO */
   IORBH         iorbh;                       /* IORB Header                */
   USHORT        cSGList;                     /* Count of S/G list elements */
   PSCATGATENTRY pSGList;                     /* far ptr to S/G List        */
   ULONG         ppSGList;                    /* physical addr of  S/G List */
   ULONG         RBA;                         /* RBA Starting Address       */
   USHORT        BlockCount;                  /* Block Count                */
   USHORT        BlocksXferred;               /* Block Done Count           */
   USHORT        BlockSize;                   /* Size of a block in bytes   */
   USHORT        Flags;
 } IORB_EXECUTEIO, FAR *PIORB_EXECUTEIO, *NPIORB_EXECUTEIO;


 Q1: What is the relationship between 'pSGList' and 'ppSGList'?

 Q2: What is the relationship between 'BlockCount' and 'XferBufLen'?

 Q3: Is RBA == LBA(logical Block Address) in SCSI CDB format?

 Q4: What is the relatioship between  'PIORB_EXECUTEIO->iorbh.CommandModifier'
     and 'SCSI CDB command' ?
      ( ex1: if we get iorbh.Commandmodifier == SCBREAD,
        SCSI_READ_6 or SCSC_READ_10  we should fill in SCSI CDB format?
        ex1: if we get iorbh.Commandmodifier == SCBREADV, How do ADD suppose
                 to know what and how many SCSI CDB should send to SCSI? )


ANSWER:
These data structures are documented in the Storage Device Driver Reference.
which is part of the OS/2 Technical Library.  An online version is on the DDK.
Please ref to pages 42-44 of this reference.  In the online version, the table
of contents hierarchy is:

  - DASD, SCSI, and CD-ROM Device Manager Interface Specificaton
    -  IORB Control Blocks
        - IORB General Format
    -  IORB CommandCode Format
        - IOCC_EXECUTE_IO

The information included in these sections should answer your questions.




!STORAGE________________________________**********
March 11, 1994
QUESTION: (Ref: 974)
Q1. I am currently developing OS2 ADD driver for our SCSI controller card.  I
    use IBM2SCSI.ADD as a sample source code to develop our , say, OEM.ADD.
    It seems to me we have a path from OS2DASD/OS2SCSI/OS2ASPI to SCSI CDB
    format like:  IORB->DCB->SCB->ABIOS_RB or passthu_scsi_cdb

    But OEM.ADD doesn't use ABIOS.  Should I keep the same path
    IORB->DCB->SCB->OEM_RB/scsi_cdb?  If yes, is there any detailed ADD driver
    specification describing data structures of DCB, SCB other than the IORB
    spec in the DDK?

A1. Yes, the detailed info is in the PS/2 Hardware Reference Manual.  The
    following information comes from the online database of IBM publications:

      ORDERNO   S84F-9809                  SUFFIX: 00
      TITLE     PS/2 HARDWARE INTERFACE TECHNICAL REFERENCE COMMON
                INTERFACES
      STITLE    PS/2 HARDWARE INTERFACE TECHNICAL REFERENCE COMMON INTERFACES
      ABSTRACT  This manual contains the Microprocessor and Instruction
                Set, System Board I/O Controller, keyboards, characters,
                keystrokes, VIDO Subsystem and compatibility information
                for PS/2 Micro Channel Products.
                It is intended for those that develop hardware and
                software products for PS/2 Systems and that understand
                computer architecture and programming concepts.
                This is one of three manuals that make up the PS/2
                Hardware Interface Technical Reference Library.
      DESCRIBE  Manual, 1000 pages, 10/90
      PRICE     SELL PRICE:       $75.00
      DATE      AVAILABLE DATE:    02/91
      SECURITY  UNCLASSIFIED
      NOTE      Price is subject to change, you will be billed
                at the price in effect at the time of shipment.

    If you wish to order this, call the PC Bookline at (800)426-7282.
==============================================================================

Q2. Our OEM.ADD will download Adapter local CPU microcode, and microcode will
    handle scsi queue.  Do I still need to have multiple IORB_QUEUE?

A2. The Queuing count has the recommended commands to queue for the unit.
==============================================================================

Q3. After installing OS2 and OS2 DDK, according to DDK "storage device driver
    reference",

      - Between OS2SCSI.DMD and OS2 kernel/file system, we need IBM SCSI.SYS

      - Between OS2ASPI.DMD and OS2 kernel/file system, we need Aspi Driver
        before we can have a complete path to test OEM.ADD ( and scanner.sys,
        optical.sys,xxxCDR.sys, xxxTape.sys)

    Which of these drivers is supported by IBM and how do we get hold of it?

A3. Yes, this is correct; the manufacturers most of the time ship the drivers
    with the hardware.  Other than that I don't know where to get the drivers
    for these hardware devices.




!BASE !I/O !OTHER_______________________**********
March 11, 1994
QUESTION: (Ref: 942)
When I insert "dprintf()" call in my ADD driver, When I single step through
dprintf function:  inside "PollC PROC" in al,dx (get COMport status), I got
following msg on my Kernal Debugger Screen:

           DelayHardError  SYS3186: 4 string(s):
           Pid 0017  Tid 0001 Slot 002b  HobMte 02ce

Can you tell me what's wrong?


ANSWER:
SYS3186:
Sys3186 is a privileged instruction exception.  It occurs when an attempt is
made to execute an instruction whose operation is not allowed in the current
machine mode.  For example, an attempt was made to execute an instruction in
user mode that is only allowed in kernel mode.  If you are the developer of
this program, refer to the information in the register.

DelayHardError:
The system saves the hard error information until the process's exit list
routines are called and its resources have gone away.  This is done because
the process that is dying due to a GP fault may own resources that are needed
to display the hard error popup.  This is what the DelayHardError means.

DelayHardError is known to occur due to non re-entrant string functions.  It
has also been known to occur when memory allocated with DosAllocMem is not
committed.  Adding the PAG_COMMIT flag to the DosAllocMem parameters, or using
DosSetMem to commit the memory, will fix this particular problem.

Debug technique:
What he should do is create a KDB.INI file in the root of his boot drive which
contains the following two lines:

      VSF *
      G

This file will be loaded automatically by the Kernal debugger at boot and
tells the debugger to capture all faults.  The debugger will then stop on the
actual line which causes the trap and display that line.  The developer can
then enter the 'ln' command to display the name of the routine causing the
trap, and the command '.k' to show the call stack.  With this information he
should be able to figure out the problem.




!OTHER !STORAGE ________________________**********
March 11, 1994
QUESTION: (Ref: 936)
Our ADD works fine with one (single) drive - tested over 72 hrs under heavy
database I/O.  Adding another host adapter doesn't create a problem - device
table shows 2 adapters, one of them without devices attached, but system works
without a hitch.  However, adding one more drive (to the same adapter, or the
second adapter) results in either a 'hang' condition or the message

            "DelayHardError SYS3175:  4 string(s):
             Pid 0001   Tid 0007   Slot 0007  HobMte 0000
             sysinit "


ANSWER:
SYS3175:
The sys3175 is an access violation exception error, and was generated when an
attempt was made either to load or store data in an inaccessible location, or
to execute an inaccessible instruction.

DelayHardError:
The system saves the hard error information until the process's exit list
routines are called and its resources have gone away.  This is done because
the process that is dying due to a GP fault may own resources that are needed
to display the hard error popup.  This is what the DelayHardError means.

DelayHardError is known to occur due to non re-entrant string functions.  It
has also been known to occur when memory allocated with DosAllocMem is not
committed.  Adding the PAG_COMMIT flag to the DosAllocMem parameters, or using
DosSetMem to commit the memory, will fix this particular problem.

Debug technique:
What he should do is create a KDB.INI file in the root of his boot drive which
contains the following two lines:

      VSF *
      G

This file will be loaded automatically by the Kernal debugger at boot and
tells the debugger to capture all faults.  The debugger will then stop on the
actual line which causes the trap and display that line.  The developer can
then enter the 'ln' command to display the name of the routine causing the
trap, and the command '.k' to show the call stack.  With this information he
should be able to figure out the problem.




!STORAGE________________________________**********
March 11, 1994
QUESTION: (Ref: 923)
We have developed drivers for two products:  a floptical drive and a parallel
port/IDE disk drive.  The floptical is on a SCSI bus with an ADAPTEC adaptor
card.  When only the floptical drive is connected, it shows up as a floppy
drive on drive D. When only the disk drive is connected, it shows up as a hard
disk on drive D. When both are connected simultaneously, the floptical shows
up as a floppy on drive D and the disk shows up as a hard disk on drive E.
However, the hard disk doesn't function properly but the floptical drive does.

Our questions are as follows:

1. Is the sequence hard disk (C:), floppy (D:), hard disk (E:)  an allowable
   sequence?  Is there an OS/2 restriction?

2. If we treat the floptical like a hard disk by not setting UF_REMOVABLE,
   would the DMD driver function correctly if we change media?  How are
   magneto-optical (MO) drives or other removable media devices treated?


ANSWER:
1. I took a look at the source code of OS2DASD.DMD.  As far as I can see, I do
   not think that the assignment of the drive letter is correct.  I would like
   the customer to check the following:

      Set a break point in _Setup_Partition_VolCBs in OS2DASD, and please
      check the value of _NumFixedDisks.  ( Please refer to the file
      DDK\SRC\DEV\DASD\OS2DASD\DMINIT.C )


2. There is sample code of the lock drive filter in the directory
   DDK\SRC\DEV\DASD\LOCKDRV.  It should prove helpful for the customer.  Also
   check LOCKDRV.DOC in the same directory.




!BASE !VIDEO !OTHER_____________________**********
March 11, 1994
QUESTION: (Ref: 920)
Q1. Is there any function a physical device driver can call, at or just after
    init time, which will enumerate the video modes that the video driver
    supports?

A1. On DDK v1.1 there is a file \ddk\src\dev\mouse\ioset.asm.  The function
    IOMW_SM is exported by this file.  It will allow you to check the video
    mode at run time.  You may be able to use this.  The problem at init time
    is that things may vary depending on the driver.  If this function does
    not allow you to do what you want, please provide us with more details
    about what you are trying to do.
==============================================================================

Q2. The main thread of an application creates another thread.  This secondary
    thread makes a call to a physical device driver and the driver block the
    thread.  Some time later, the main thread decides to kill the secondary
    thread(while it is still blocked).  What returns(messages, events, ...)
    to tell the device driver that the OS that the OS has killed the blocked
    thread?

A2. In the PDD Reference, on page 17-21, the dev help "DevHlp_Block" is
    defined with error conditions.
==============================================================================

Q3. An application is using semaphores to communicate with a physical device
    driver.  Assume that the device driver has done all the good stuff
    required to turn the semaphore into a handle it can use.  What happens if
    the application quits without telling the device driver anything?  Does
    the OS make any calls to the device driver on the application's behalf?
    Is there any way to find out a semaphore is no longer valid?

A3. A return code ERROR_SEM_OWNER_DIED is documented to be returned when
    invalid semaphores are used.




!I/O____________________________________**********
March 11, 1994
QUESTION: (Ref: 898)
Q1. We are building a special, device dependent, mouse physical driver.  Our
    driver is going to be "speical" in that we want it to work in parallel
    iwth any existing mouse device dependent driver, as opposed to replacing
    it.  We want our customers to continue to use their existing mouse as well
    as ours.  We are using the Device Driver Source Kit, Ver 1.1.

    The source code for MOUSE.SYS shoulws that MOUSE.SYS accepts a number of
    command line switches on its DRIVER= line, being:

        TYPE=
        RELAXED
        QSIZE=
        STYPE=

    The DDK describes the TYPE= switch fairly clearly, and it seems that this
    switch would be inappropriate for our use.  However, we could not find any
    documentation explaining the purpose of the other 3 swtiches.  In
    particular, the STYPE= switch may be useful in our application.  What
    information can you provide about these witches?  Are these supported in
    the mouse drivers shipped with all versions of OS/2?

A1. "TYPE=" is the key that tells the MOUSE.SYS DIDD (Device Independent
    Device Driver), the entry point, defined in the device driver header, of
    the DIDD's IDC routine.

    "RELAXED" is a key that will allow the DIDD to turn off the tests for out
    of synch packets and Hot Plug support in the interrupt handler in
    MOVE.ASM.  Hot Plug support allows a user to unplug a PDI attached mouse
    and reattach it while OS/2 is running.  Without this, OS/2 must be
    re-booted to get the PDI running.  Without this, OS/2 must be re-booted to
    get the PDI mouse support back by re-loading the MOUSE.SYS driver during
    boot.  Re-synching packets were added to fix problems where the mouse
    would get out of synch with the three data bytes passed into the PDI
    interrupt routine due to loss of a byte or an additional byte, (spurious
    interrupt).

    "QSIZE" is the size of the DIDD internal data queue.

    "STYPE=" is similar to "TYPE=" except that it allows a secondary device
    pointing device to be attached to the system.  MOUSE.SYS will handle all
    data coming from both devices and pass them up the chain.  This support
    was added in OS/2 2.0 MOUSE.SYS to support customers who had an IBM 8516
    Touch Display.  but preferred to use the serial mice that they already
    owned.  (The IBM Touch display is designed to have the PDI mouse plug into
    the back of the 8516 display and the display itself is plugged into the
    PDI port of the system unit.  The old OS/2 1.x versions of the DDDD
    (Device Dependant Device Driver), were added to the OS.2 2.1 product disks
    for use in this environment.  Any customer written DDDD can use this
    interface though.

    MOUSE.SYS initialization code looks for the STYPE switch and loads that
    driver first.  If a load error occurs, MOUSE.SYS will fail to load itself.
    If the Secondary Type, (STYPE), loads successfully, MOUSE.SYS
    initialization will continue its auto detection for other pointing devices
    in the order described in the init routine of INIT.ASM.  The danger of
    reloading support for the same device, lets say a serial MS device on
    COM1, is handled by the STYPE DDDD if it puts a zero in the 40:0 data area
    which is how COM.SYS and MOUSE.SYS detect if there is support for a serial
    device.  When MOUSE.SYS auto detection looks for support at 40:0 and sees
    the zero, it does not try to detect a mouse on that port.  This clearing
    of 40:0 BIOS data area scheme shows why MOUSE.SYS MUST be positioned
    BEFORE COM.SYS in the CONFIG.SYS file
==============================================================================

Q2. What is 'single queue mode?'  Throughout the source code this mode
    controls the operation of the device independent mouse driver.  What does
    it mean?  Is it important to a device dependent driver hooking in though
    the IDC interface?

A2. Single queue mode references the Single Input Queue which is the interface
    between the Keyboard / Mouse device drivers and screen group one, (PM and
    eventually, the Workplace Shell).  All other screen groups have there own
    MOUSE.SYS internal queue for processing data.  DDDD's do not have to worry
    about this state unless they are making changes to that logic in MOUSE.SYS
    and then they must supply the new MOUSE.SYS with their DDDD anyway.
==============================================================================

Q3. What is 'extended mouse interface'(EMI)?  Again, there are numerous calls
    and references through the source code to the EMI.  We are wondering
    wheter this might be an appropriate method through which to implement our
    (parallel) device dependent driver.  And, as in question 1, is EMI
    supported by the mouse drivers shipped in all previous versions of OS/2?

A3. EMI is support for the OS/2 Pen Product which is shipped separate from the
    OS/2 product.  The support added to OS/2 2.1 GA, was to detect the PenPM
    device driver and connect a special IDC to communicate mouse events to the
    rest of the system.
==============================================================================

Q4. We are interested in the answer to question about EMI.  We wrote a mouse
    driver, then a Windows for Pen driver for Microsoft.  Likely we would want
    to continue on to develop the Pen support for OS/2 at some point.

    Would knowing more about EMI and the Pen Product now significantly
    influence the mouse driver we are developing?  If so, where should we go
    to get more info?

A4. There is no PEN specific source code availible on the DDK CDROM.  The only
    advice I can give the developer is to make sure that the MOUSE.SYS source
    code that has reference to EMI not be changed,

    They may want to reference the Pen/PM Device Driver Reference which is
    included in both the on-line books in the DDK and is one of six hardcopy
    books included in the OS/2 Technical Library.  This can be ordered by
    calling 1-800-633-8266 referencing part number 10G3356, (part number for
    all six references).




!BASE !OTHER____________________________**********
March 10, 1994
QUESTION: (Ref: 976)
I am trying to establish communications between a DOS Vdd and a PM
application.

Is there a more efficient way to share memory than to allocate a page granular
block in VDM global memory then ...

  Copy to the block from PM context ...
  arm the context hook and ...
  copy from the block to DOS context.

This requires two copies, not to mention the buffer setup on each side.  I
guess I can eliminate one copy by having the VDD allocate and pass pointers
back to the PM caller.

Is there a way to share memory between a DOS VDM and a PM app?


ANSWER:
There is no alternative other than what you are already doing.




!OTHER__________________________________**********
March 10, 1994
QUESTION: (Ref: 972)
Is the Kernel Debugger for the new Servicepak (OS/2 2.1 version) going to be
provided on the DUDE?


ANSWER:
The Kernel Debugger for the new Servicepak was placed in the MAIN FILE area of
the DUDE on 03/01/94.  It will be included in the next release of the DDK
(version 1.2) scheduled for release later this month.  After a reasonable
amount of time, the KDB will be removed from the DUDE.




!OTHER__________________________________**********
March 10, 1994 (Ref: 949)
QUESTION:
I recently received a publication named the DDK Update.  This publication
listed a printed manual "Physical Device Driver Reference" Part #10G6266 as
being available for ordering at 800-633-6266.  I called that number and three
others with no luck!  The DDK Update listed a name at the address below as a
contact.  Since I didn't see his name on the list of users, could you please
forward this message to him for me?

I am trying to obtain a printed version of the manual above and nobody seems
to know what it is or where to get it even though the DDK Update lists the
part number!  Please leave me a message as to how to get ahold of this manual.


ANSWER:
The printing has been delayed and the document is not yet available at that
800 number.  The document should be available by the Technical Interchange
Conference scheduled for April 25, 1994.




!SCSI___________________________________**********
March 10, 1994
QUESTION: (Ref: 949)
I have a SCSI HDD which is partitioned by FDISK.  FDISK defines the boot
sector and data area.  The boot sector area is defined as 1mb, and the data
area starts on the 1mb offset.

If I manipulate the boot record to be less than 1mb, will OS/2 recognize the
HDD?


ANSWER:
The Boot Record has to be 1Meg.  If it is less that 1meg, OS/2 may not see
the drive




=================== Administrative Stuff ===================
________________________________________**********
March 30, 1994
