This is file: 01_95QA.TXT

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

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

The following KEY WORDS are supported in this file.

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

!OTHER__________________________________**********
January 31, 1995
QUESTION: (Ref: G73)
We want to develop PDDs for different function parallel I/O cards with
assembly and C languages.  What kind of software do we need?  Could you list
all the tools in the market, indicating the version, company and where can we
buy them, please? We need to evaluate them, then choose some of them.


ANSWER:
COMPILERS :
32 bit Device Driver Development - IBM CSet++ - Current Version
16 bit Device Driver Development - Watcom C/C++ v9.5/10

ASSEMBLER :
Microsoft MASM 6.0

DEBUGGER:
IBM     - ASDT32, DEBUGO
Non IBM - Periscope Source Level Debugger




!OTHER__________________________________**********
January 31, 1995
QUESTION: (Ref: G70)
We are currently developing device drivers and main code under OS/2 V2.11
using the C Set++ Version 2.0 compiler.  Can we use this compiler under WARP
and are all tools such as the debugger compatible?


ANSWER:
The IBM CSet++ 2.0 is recommended for 32 bit Development and is compatible
with WARP.




!OTHER__________________________________**********
January 31, 1995
QUESTION: (Ref: G61)
Please give us a working-coded-example of a PDD that writes to memory
locations starting at 1 Meg with a range of 64K in a VDM.


ANSWER:
Each VDM has 4MB of linear address space that is mapped to a single page
table.  The 4MB linear address space for each VDM is reserved in the system
area.

DOS applications running in a VDM utilize real mode addressing.  A 20-bit real
mode address in the seg:off form can refer to a physical address within the
VDM's 1MB address space.

If the VDM makes an IOCtl call to your device driver with pointers in the
private data and/or parameter buffers, the driver must take an extra step to
ensure the pointers are converted correctly.  The driver checks the
TypeProcess variable in the local info seg structure to determine if the
application is a VDM application (bit 1 == 1).  If it is a DOS application,
the driver allocates a GDT selector and converts the seg:off address to a
VDM-relative physical address by shifting the segment left 4 bits and adding
in the offset.  This is the same way the physical address is calculated in
real mode for a real-mode application.

The driver then calls LinToGDTSelector with the 20-bit physical addr of the
VDM application's buffer and/or parameter address.  This call maps the 20-bit
physical address of the caller's address using a GDT selector which can be
accessed at kernel or interrupt time.  The selector should be released by a
call to FreeGDTSelector when the driver is finished with it.

It is important to note that normally LinToGDTSelector requires a 32-bit
linear address and not a 20-bit physical address.  This is possible only
because LinToGDTSelector can find out that the current process making the call
is in a VDM.  If LinToGDTSelector determines that the caller is a VDM
application, it converts the 20-bit real address to a valid 32-bit linear
address before mapping it to GDT selector.

The 64KB area above 1MB area is called the A20 wrap area.  In a VDM the
wrapping of these addresses is emulated by the page table entries for the
range between 1MB and 1MB + 64KB being set to the same as the page table
entries for the first 64KB of the VDM.  Using the GDT allocated, PDD can write
to memory.  There is no special way to write to memory area between 1MB and
1MB + 64KB.

Also please refer to the Red Book - Volume 2 DOS & Window Environment, which
is also contained in DevCon.




!OTHER__________________________________**********
January 31, 1995
QUESTION: (Ref: G50)
I am writing a PCMCIA ".ADD" driver for an NCR product being developed.  As I
was reading documentation on the PCMCIA Card Services I read something that I
found kind of disturbing...  That Card Services are only available for

        1. OS/2 native device drivers

        2. OS/2 physical device driver types

This indicates to me that ".ADD" drivers may not use these services yet.  Is
this a true statement?  If so, is there a 3rd party vendor providing card
services that allow ".ADD" drivers to be developed under OS/2 2.1?

The reason for this mail in the first place is that I am having trouble
getting the card service I need.


ANSWER:
The OS/2 2.1 PCMCIA BBS and the OS/2 Warp shrinkwrap packages both support
.ADD drivers. The OS/2 2.1 shrinkwrap package does not support .ADD drivers.
The easy way to tell if it will support .ADD drivers is to check the Card
Services (PCMCIA.SYS) statement in CONFIG.SYS. If it reads BASEDEV=PCMCIA.SYS
then .ADD drivers are supported. If it reads DEVICE=drive:\path\PCMCIA.SYS it
does not support .ADD drivers and you should either get the BBS package for
OS/2 2.1 (The OS/2 BBS number is (919) 517-0001 and the file name is
OS2PCM.ZIP) or move to OS/2 Warp.




!VIDEO__________________________________**********
January 31, 1995
QUESTION: (Ref: G49)
I have a question about the OEMHLP$ device driver OEMHELP_FUNCTION_ADPATER
IOCtl function.

On our hardware, this function call returns with only the VGA_DEVICE bit set
(0x08).  On standard VGA hardware, this function returns with BOTH the
VGA_DEVICE and CGA_DEVICE bits set (0x0A).

Because of the way the code in the BVHVGA.DLL routine getVideoType is
designed, this causes both the CGA_BIT and VGC_BIT bit flags to get set in the
VideoHardware.fVideoType field.

This in turn causes the SetMode routine to fail when the standard VGA display
driver tries to set the 640x480 4bpp VGA mode causing a critical error within
the VGA driver.

I would like to understand what the OEMHLP$ driver does in order to determine
what value to return for this routine so that we can try to correct this
problem.

Does OEMHLP$ use information from the VGA BIOS or does it rely on actually
twidling with the hardware?

I can get the VGA driver to come up if I modify the BVHVGA.DLL routine to
explicitly clear the CGA_BIT and set the VGC_BIT flags instead of toggling the
state as is currently done, however, this solution is not a very acceptable
solution for us because that means that a standard OS/2 VGA installation would
not boot on our hardware, and would make installing our drivers quite
difficult.


ANSWER:
The CGA bit gets set if a memory check at 0xb8000 is successful.  The code
which xor's the CGA and VGA bits in the getvideotype should probably have been
Anded with the Not Mask, instead of toggling, but we are not too familiar with
the code, so we can't really recommend the fix.  It will be impossible for you
to fix the OEMHLP, as it belongs to the loader.  We would suggest that you
investigate why the memory check is failing.  The sequence is:  IDC master
mode is set to CGA (ax=0xbf02, bh=4, int 10) and a mode 3 is set (ax=3, int
10) followed by a memory test at 0xb8000 where two patterns, 16bytes apart,
are written and read back.  You will have to do this test yourself as the
loader is not debuggable.  We therefore suggest that you write a small DOS
program that does this, if the reason for failure is not obvious from the
description of the check.

If you can't make your device respond to this memory check thru some
configuration (or a BIOS fix), the only options are to get your hardware here
and treat this as a critical full-pack problem and fix the bvhvga for Warp
full-pack.  This would give you atleast installation of the full-pack.  The
other alternative is to provide an installation patch, which is both expensive
and cumbersome for the users.




!I/O____________________________________**********
January 31, 1995
QUESTION: (Ref: G44)
I am developing a PDD for our parallel port modems, for OS/2 2.1 and OS/2
WARP.

Q1:  The Input/Output Device Driver Reference for OS/2 indicates that I can
have a PDD handle a COMn device instead of the ASYNC PDD, pg142.  It states
that in order to claim ownership of the device, I must first initialize before
the ASYNC PDD, and do one of the following:

      -  Not allow the ASYNC PDD to receive an INIT request packet for the
         given device name

      -  Put and invalid I/O address in the corresponding 40: area

      -  Exclusively own the appropriate interrupt level at initialization
         time

How do I prevent ASYNC PDD from getting the INIT request packet?

A1.  The Async PDD & your PDD need to have the same name and the same Device
Header (as specified in ATCOM.ASM in the DDK).  The Async PDD should be loaded
before your PDD.  The system will try to deinstall the Async PDD before
loading and initializing your device driver.  If the Async driver fails to
deinstall by returning RPERROR in the status field and the error code
ERROR_BAD_COMMAND (0x03) then you prevent the sending of the INIT request
packet to second driver.  In other words, your PDD will not be installed and
the Async PDD DEINSTALL will not take place.
==============================================================================

Q2. Chapter 10 Physical Asynchronous (RS232-C) Communications Device Driver,
section Initialization/Resource Management, page 142, paragraph 3, states:

   "The device driver does not deinstall a device if the system requests it.
    If another device driver wishes to support a port already supported by
    this device driver, it needs to be initialized BEFORE this ASYNC device
    driver. "

I am understanding this to mean my PDD would be loaded before the ASYNC PDD.

A2. Your PDD could prevent the Aync PDD from claiming a COM Port by
initializing before the Async PDD and by doing at least one of the following:

       - Preventing ASYNC PDD from receiving an INIT Request Packet for the
         given COM Port.If you were to use COM2,you would have to make the
         following change in ATCOM.ASM and rebuild the COM.SYS :
                SDev   Com1Dev  -1,COM_ATTRIB,COM1start,...
         COM.SYS consequently is initialized only for COM1

       - Putting an invalid I/O Address in the corresponding 40 : 0 Data
         Area. This would be a better approach since you are not dependent
         on the modified COM.SYS.

       - Exclusively owning the appropriate interrupt level in your PDD at
         INIT time. This approach is also recommended since it does not
         depend on a modified COM.SYS

The other approach which was suggested earlier works only for the Parallel
Port in which your PDD could be loaded after the OS/2 PDD.  Ref.  I/O Device
Driver Reference - Physical Parallel Port Device Driver - Replacing the
Parallel Port Device Driver.
==============================================================================

Q3. Since communication packages do not know how to talk directly to LPT
devices, I need to redirect the packets sent to COMn device to an LPTn device.
Do I need to have another PDD handling LPT devices or can I handle it directly
from my COM PDD?

A3. You should be thinking in terms of a Character Device Monitor.  It can be
used for implementing redirection mechanism (i.e) data can be redirected from
one device to another.  For details refer to Ch-6, Physical Device Driver
Reference.  For example source refer to \ddk\src\dev\mouse directory.




!NETWORK________________________________**********
January 31, 1995
QUESTION: (Ref: G30)
Q1. I have written several NDIS MAC drivers and protocol drivers for OS/2 and
Dos.  I have a need to write provide ANDIS support for my product.  I have the
preliminary ANDIS mini-spec, and a small skeleton sample ANDIS MAC that I
obtained from your NDIS LAN workshop.  Where can I get updated info, specs,
source for ANDIS?

A1. ANDIS is used by the IBM LAN Distance product, and is currently
available, free of charge, as a separate CD-ROM (entitled "The Developer
Connection For LAN Systems").  This CD-ROM is being shipped with the DEVCON
product, Volume 5.

*)  DEVCON part number is 82G1500
*)  Telephone number for ordering DEVCON is (800) 633-8266
============================================================================

Q2. Are there some sample PCMs or Connection Managers around?

A2. There are no sample PCMs or CMs available at this time.
============================================================================

Q3. Are the Lan Distance (which I believe to be ANDIS) drivers workable with
any NDIS protocol driver, and if so, are they available for distribution?

A3. You would have to test for such compatibility on a case by case basis.




!OTHER__________________________________**********
January 31, 1995
QUESTION: (Ref: G14)
The reason I was calling was to report the following message halts the machine
when running Watcom generated EXE's created with Watcom 10.0.

##g
Internal symbol error: SegDefLinkUp
Invalid error code: 0951 - %ab5ae008
##g
eax=002a1ff4 ebx=00000000 ecx=002a1ff4 edx=00000000 esi=00000000 edi=00000000
eip=000103c4 esp=002f1ff8 ebp=00000000 iopl=2 -- -- -- nv up ei pl nz na po nc
cs=005b ss=0053 ds=0053 es=0053 fs=150b gs=0000  cr2=001e6244  cr3=001d9000
005b:000103c4 ebfa           jmp     000103c0
##be *
##g

This occurs only when running Warp 3.0 debug kernel!


ANSWER:
It appears that the kernel debugger is attempting to load in incompatible
format Watcom symbol file. So:

1. Remove the symbols from the directory where the .exe is being loaded from.
2. Invoke the Watcom compiler switch for code-view format debug information




!OTHER__________________________________**********
January 31, 1995
QUESTION: (Ref: G12)
How do I load a driver (during my driver development) without rebooting OS/2?
According to The Developer Connection News - Volume 5, page 5's Tip - it
stated that the developer can

     "simply install a small bootable partition that contains a
      line pointing to the device driver under development. No
      changes to the CONFIG.SYS files are needed between booting
      into the test environment or the development environment.
      And there is no risk of making the primary environment
      unbootable."

I would like to implement this for my driver development as well ( in order to
save the booting time).  Is there any guide or slightly more hints on how this
can be done?  It's very troublesome to reboot everytime after I change the
driver and have to reboot again to test it.


ANSWER:
What was implied in the Tip in the DevCon NewsLetter was that the Boot Time
could be reduced by having two partitions - one exclusively for test and the
other for Development.

You can load your driver only by booting and there is no way you can avoid
that.

Partition the given Hard Disk with two OS/2 boot partitions/logical drives and
configure it with boot manager.  Have one as an OS/2 boot partition/logical
disk as the development environment boot partition and the other as the test
boot partition/logical disk..  Ref OS/2 2.1 Installation Guide in Chapter
Installing Multiple Operating System.  The test boot partition could have the
DEVICE = statement in the config.sys for the test Device Driver.

You could also reduce the Bootup time by following these general guidelines:

1. Use a machine with a small FAT Partition.  Crashing an HPFS machine during
   driver development can result in files being damaged and lengthy reboots.

2. The PROTSHELL line in the CONFIG.SYS specifies the Command Shell.  Replace
   PMSHELL.EXE with either CMD.EXE or TSHELL.EXE.  CMD.EXE is a text only OS/2
   without multiple sessions.  TSHELL.EXE provides multiple OS/2 Sessions and
   is available on DevCon.




!OTHER__________________________________**********
January 26, 1995
QUESTION: (Ref: G91)
I have recently encountered a problem in calling WinCreateStdWindow.  It
appears to be unstable in some strange way.  The folks at Borland, whose OS/2
2.0 C++ compiler I'm using, claim that it's a known bug but that they aren't
certain whether it's theirs or IBM's and they are equally ignorant of any fix
for the problem.

It is quite an inconvenient problem, as it crashes the operating system when it
occurs.  The identical code will execute correctly when seemingly unrelated
code is inserted or deleted ahead of or behind it.  Does anyone at Boca have a
work-around yet...for that matter is anyone aware that there is a problem?


ANSWER:
I do not know of any problems with this function.  It would be best to contact
our DAP program (developers assistance program) for this type of question
since they deal with app related development.  You can register with the DAP
program by calling (407) 982-6408.




!I/O____________________________________**********
January 26, 1995
QUESTION: (Ref: G86)
I am developing drivers for our keypads under OS/2.  I have a package of two
disks containing IBM OS/2 2.1 Layered Keyboard Device Driver Source Kit.

At this time this is all I have.  I am looking for information about what
DDK's, assembler/compiler and debugger are needed for writing OS/2 device
drivers.


ANSWER:
Physical Keyboard Device Driver Build Requirements :
Microsoft MASM 5.1 (supplied with the DDK)
Microsoft C 6.0

Virtual Keyboard Device Driver Build Requirements :
Microsoft CL386 (supplied with DDK)

An alternative to Microsoft C 6.0 for your own 16 bit Device Driver Development
would be Watcom C/C++ v10.0

The Kernel Debugger, ASDT32 & Debugo are the Debuggers that come with the DDK.

You could also explore the possibility of using Periscope, which is a Source
Level Debugger.




!VIDEO__________________________________**********
January 26, 1995
QUESTION: (Ref: G49)
I have a question about the OEMHLP$ device driver OEMHELP_FUNCTION_ADPATER
IOCtl function.

On our hardware, this function call returns with only the VGA_DEVICE bit set
(0x08).  On standard VGA hardware, this function returns with BOTH the
VGA_DEVICE and CGA_DEVICE bits set (0x0A).

Because of the way the code in the BVHVGA.DLL routine getVideoType is designed,
this causes both the CGA_BIT and VGC_BIT bit flags to get set in the
VideoHardware.fVideoType field.

This in turn causes the SetMode routine to fail when the standard VGA display
driver tries to set the 640x480 4bpp VGA mode causing a critical error within
the VGA driver.

I would like to understand what the OEMHLP$ driver does in order to determine
what value to return for this routine so that we can try to correct this
problem.

Does OEMHLP$ use information from the VGA BIOS or does it rely on actually
twidling with the hardware?

I can get the VGA driver to come up if I modify the BVHVGA.DLL routine to
explicitly clear the CGA_BIT and set the VGC_BIT flags instead of toggling the
state as is currently done, however, this solution is not a very acceptable
solution for us because that means that a standard OS/2 VGA installation would
not boot on our hardware, and would make installing our drivers quite
difficult.


ANSWER:
The CGA bit gets set if a memory check at 0xb8000 is successful.  The code
which xor's the CGA and VGA bits in the getvideotype should probably have been
Anded with the Not Mask, instead of toggling, but we are not too familiar with
the code, so we can't really recommend the fix.  It will be impossible for you
to fix the OEMHLP, as it belongs to the loader.  We would suggest that you
investigate why the memory check is failing.  The sequence is:  IDC master mode
is set to CGA (ax=0xbf02, bh=4, int 10) and a mode 3 is set (ax=3, int 10)
followed by a memory test at 0xb8000 where two patterns, 16bytes apart, are
written and read back.  You will have to do this test yourself as the loader is
not debuggable.  We therefore suggest that you write a small DOS program that
does this, if the reason for failure is not obvious from the description of the
check.

If you can't make your device respond to this memory check thru some
configuration (or a BIOS fix), the only options are to get your hardware here
and treat this as a critical full-pack problem and fix the bvhvga for Warp
full-pack.  This would give you atleast installation of the full-pack.  The
other alternative is to provide an installation patch, which is both expensive
and cumbersome for the users.




!I/O____________________________________**********
January 26, 1995
QUESTION: (Ref: G36)
All of the documentation I have seen states the OS/2 system 'mode' command
uses standard ioctl calls to accomplish its function.  I encountered a problem
handling the baud rate functions with this command.  Placing traps in the
driver, I found out that the 'mode' command uses 43h and 63h enhanced mode
ioctl calls.  My question is related to the documentation in the Physical
Device Driver Manual on the Developer Connection CD.

Under the heading 'Generic IOCTL, CAT1 ASYNC ...'  there is a description for
the 43h IOCtl.  In the 'parameter description', under 'fraction' it says to
use the baud rates of 76800, 115200, 230400, and 345600, use the 74h ioctl.
Somewhere else in the description it said that the 43h could be used for 10BPS
to 57600BPS.  I am confused, the description for the 74h says it is Query
Enhanced Mode Parameters, I do not see any way of changing the baud rate to
the higher values.  When I try to set the baud to a value above 57600 it is
ignored.

Q1. Does setting the enhanced parameters with the 54h tell the system to raise
    the limit allowable in the 43h ioctl?

A1. Function 43h supports 10 bps - 345600 bps.  You can use IOCtl 43h for bit
    rates greater than 57600 bps.  The corresponding query function would be
    IOCtl 63h.  Function 54h is used if your hardware supports the Enhanced
    Mode Operations - DMA Mode or Enhanced FIFO Mode.
==============================================================================

Q2. I don't see what bearing the 74h query has on selecting the higher rates,
    unless the 43h uses it to verify that it has enhanced capabilities.  But
    even then it is a query and cannot be used to set these parameters, can it?

    If this is the case, I really don't want to set the enhanced mode since the
    documentation states that DMA must be supported and this is not the case.

A2. Function 74h is indeed a Query Function and is not used to set the Bit
    Rate.  This should be used if your Hardware uses the Enhanced Mode.
==============================================================================

Q3. Are there any other discussions covering the 43h, 63h, 54h and 74h enhanced
    parameter IOCtls?

    I searched all libraries on the Developer Comnnection CD under the Browser
    and found the information mentioned above, but as I stated, it is still not
    clear to me what is happening.

A3. Refer to the Physical Device Driver Reference on DevCon DDK Version 1.
==============================================================================

Q4. I also noticed in the descriptions of the 54h and 74h that they are not
    supported in the COM.SYS driver.  Does this driver simply ignore them as
    invalid?

A4. The com.sys driver has never provided support for ioctl 74h and 54h.  What
    it has provided is entry points for these ioctls for the set/get.  These
    ioctls are for supporting enhanced (DMA) hw.  74h still exists but will
    only do a get of the default (no support).  The Set Enhanced used to allow
    setting to the default but nothing else.  This was dead code since you
    could never set it to anything useful, so now defaults to error to reduce
    the size of the driver.  It returns an RP Status = STDON | STERR |
    ERROR_I24_GEN_FAILURE.

    The com.sys only supports up to 57600.  Other drivers could be written for
    hw which could support >57600.  In that case they will use IOCTL 43h/63h
    for setting an enhanced baud rate.

    Our implementation is to support non-enhanced UARTs up to 57600.  This has
    nothing to do with the ASYNC IOCTL set.
==============================================================================

Q5. The reason I ask is that the 74h was called during the execution of the
    'mode' command when I was trapping calls to my driver.  Or is this a case
    where I have some default value set in my driver, without knowing it, that
    tells the system to make this call?

A5. Refer to A4.
==============================================================================

Q6. Just as a matter of curiosity, when did these ioctls come into existence?
    Was it release 2.0, 2.1, or before?  Just curious.

A6. These IOCtls were documented with the OS/2 2.0 Release.




!VIDEO__________________________________**********
January 26, 1995
QUESTION: (Ref: G35)
Q1.  Is there a way to determine from within a Windows app whether the Windows
session is running seamlessly?  I am aware of the Int 2F call to determine
OS/2 version, and am wondering whether there is a way to "detect seamless"?

A1.  There is no documented way to detemine from within a Windows App whether
the Windows Session is running seamlessly.  You could however attempt the
Device Escapes( ) from Win Shield & GDI to Seamless Windows Driver.

Invoke

     rc = Escape ( hDC, SEAMLESS_ESC_ENABLE, ncount, lpIndata, lpoutData) ;

from the given Windows application

If the call returns success the Windows application is running in a seamless
Window...

Ref: Device Escapes() from Winshield and GDI to Seamless Window Driver
     Chapter Seamless Windows Support -- in Display Device Driver Ref.
==============================================================================

Q2.  Also, is there a list of the available OS/2-specific Int 2F calls
anywhere?  Eg, the list might contain Int 2F/4010 - Get OS/2 version, and Int
2F/4011 - Communicate with VDD, ...

A2. Refer to Display Driver Ref .. Index pages for some of the Int 2F calls:

   Int 2F/4001h  Switch DOS Application to BackGround
   Int 2F/4002h  Switch DOS Application to ForeGround




!I/O____________________________________**********
January 26, 1995
QUESTION: (Ref: G25)
I looked in the DDK and there is source for a keyboard device driver
'IBMKBD$'.  This device driver has an IDC entry point to handle sending
generic data bytes to the keyboard (IDC function 14).  However, I cannot find
any documentation on how to access this IDC function from my device driver.
It seems that the IDC interface is so specialized that no one talks about, not
even Steve Mastrianni.

Q1:  I know you call the DevHlp function 'AttachDD' to get the IDC
      entry point but then what?

A1:  The 'AttachDD' function returns to you the code segment, offset,
      and data segment.  You use the code segment and offset as a
      function call.  If you have questions, refer to the example in
      the KBDINIT.C code.  This function can then be called like any
      other function.

      DevHlp_AttachDD returns the the following - DS of the target
      drivers IDC entry point and CS:IP of the IDC entry point of
      the target driver.  (Ref: PDD ref, AttachDD DevHlp).

      The steps to be followed would be:

      - Call AttachDD with driver name and pass address of 12 byte
         structure into which system returns DS,CS,IP values of the
         IDC entry point.

      - When you want to call IDC entry point, load DS with IDC entry
         point DS, make far call to CS:IP.

      IDC entry point can be called only from R0.
==============================================================================

Q2:  How are parameters passed to the IDC functions from assembly
     language?  Are parameters passed in registers or pushed on the
     stack?

A2:  They will be pushed on the stack.  For questions, refer to the
     file kbd\kbdbase\kbdidc.asm, function DD_Entry (first function).

     NOTE: Because IBMKBD is written in 'C' parameters are passed on
     the stack.
==============================================================================

Q3:  What are the parameters passed?

     I do not have the correct compiler to compile this device driver
     (we have Microsoft C 7.0 which cannot be used to compile device
     drivers.  I am doing all device driver development in assembly
     language and I would rather not develop a full keyboard device
     driver).

A3:  Three USHORTs (16 bit).  The first is the function,  the second
     is the data or offset to a structure, and the third would be
     the structure segment.  Refer to the documentation to get
     the structure definition or you can look in the header
     (KBDDD.H).  Use the CmdStruc.
==============================================================================

Q4:  Where can I get a pre-compiled version of IBMKBD.SYS or any other
     keyboard device driver that has a function to send generic data
     to the keyboard?

A4:  The Source Code for IBMKBD$ is available on the DevCon DDK
     Version 1.
==============================================================================

Q5:  Does the keyboard driver that comes with OS/2 (KBD$) have an IDC
     function that sends generic output to the keyboard?  If it does,
     how do I access it from my device driver in assembly language?

A5:  No, it does not have an IDC interface for passing generic
     commands.  It's IDC interface is used to convey information to
     OS/2.




!MISC___________________________________**********
January 26, 1995
QUESTION: (Ref: G19)
The RMBASE.ZIP file contains a *.INF file, which is nice.  Where does one
obtain the *.H files needed to make actual use of RM?


ANSWER:
The relevant Header files are in DevCon DDK Version 1.
DDKX86\SRC\DEV\RESOURCE\RSM_H\RMBASE.H
                             \RMCALLS.H
                             \RMIOCTL.H




!MISC___________________________________**********
January 26, 1995
QUESTION: (Ref: G15)
Assumptions:

1) All apps that call the PDD are OS/2 2.x or greater 32 apps (i.e.  no DOS,
WIN-OS/2, or 16 bit OS/2 app).  The main call is DosDevIOCtl.  Memory accesses
happen at Task Time NOT Interrupt time.

2) The memory mapped hardware has area greater than 64K that need to be
mapped.

Questions:

1) Calling DevHelp_VMAlloc with 0x30 for the Flags(i.e.  EAX) a Physical
Address of 0xC000FE00, and 0x40 for the Size(i.e.  ECX).  DevHelp_VMAlloc
returns with the Carry clear and EAX has a value of 0x230000.  Note:  bit 4 is
set we are mapping PHYSICAL Memory!  Up till now everything seems normal and I
have traced this with the Kernel Debugger so I am in the proper thread.  I now
dump the contents using the physical address and I get the values I expect.
Now I dump the content using the Linear address returned by
DevHelp_VMAlloc(i.e.  0x230000) and values are all 0xff.  Why?  How can this
happen?  The thread is running at a priority of REAL TIME.  This only happens
in one place in our app all other calls from our app that uses this same code
the mapping seems to work correctly.

2) I have tried using other values for the Flags such as 0x32, 0x38, 0x3A and
DevHelp_VMAlloc always returns with the Carry set thus DevHelp_VMAlloc failed.
Why?  These are values the DDSC suggested.

3) Given a Linear Address can the Kernel Debugger tell one the Physical
Address for that Linear Address?  If so how?

I am loading EDI with the Linear Address, which points to the variable
holding the Physical Address.


ANSWER:
EDI should be loaded with the Linear Address ,which points to the variable
holding the Physical Address and should not be loaded with the Actual Physical
Address in the DevHlp_VMAlloc Call.

MOV   AX,DS    ;AX holds the Selector
MOV   ESI,OFFSET PhysAddr  ;ESI holds Offset of Variable
MOV   DL,DevHlp_VirtToLin
CALL  [Device_Help]

MOV   ECX,40h  ;Size
MOV   EDI,EAX  ;DevHlp_VirtToLin returns the Linear Address in EAX
MOV   EAX,30h  ;Flags
MOV   DL,DevHlp_VMAlloc
CALL  [Device_Help]

There is no utility in the Kernel Debugger to find the Physical Address given
its Linear Address.


The memory allocated by VMAlloc can be specified with attributes of FIXED (bit
1) and CONTIGUOUS (bit 3) set.

When we are providing physical memory address (bit 4 set) to be mapped to a
linear address by VMAlloc, we cannot ask VMAlloc for fixed/contiguous memory.
Hence we get errors while using flag values of 0x32,0x38,0x3A.




!VIDEO__________________________________**********
January 26, 1995
QUESTION: (Ref: G10)
I've written the world's simplest PDD whose sole purpose in life is to return
an application-accessible pointer to the start of Graphics adapter memory (for
a proprietary video adapter).  The heart of it is a call to DevHelp
PhysToUVirt.

I have confirmed that the driver loads and is properly accessed thru IOCTL.
Furthermore, within the driver, the adapter memory is visible and I can draw
on the screen.

The application gets the selector:offset from the driver (I've verified that
the data is passed properly, that is to say that the numeric values used in
the driver and received for use by the app are the same).

However, the ap traps and I get an exception code 0005 immediately on
indirection thru the pointer.  What's up?


ANSWER:
Verify the request-type defined for this call.  Since the driver can access
the adpter memory, it seems the segment descriptor has not been set up with
application privilege.

The virtual address returned by PhysToUVirt should not be used for any sys.
calls since the descriptor is a fabricated one.

Refer to "Device driver for Memory Mapped Adapter" code (Appendix - C) user
RPIOCTL case, subcase 0x02 in Mastrianni's book.

If you are using DDK v1.2 or earlier, the DHCALLS.LIB had a bug in
PhysToUVirt.  This bug has been fixed in the DDK latest Release-DevCon DDK
Version 1. Please refer to the file DDKX86\SRC\DEV\DASD\DEVHELP\DHCALL2B.ASM

After the initial declarations, the 32-bit physical address is loaded into
AX:BX, the length of the segment is loaded into CX, and the values of the
flags and tag are loaded into DH and SI respectively.  Following the call to
the DevHelp function, the virtual address is found in ES:BX.  The code
*SHOULD* put this virtual address into the space pointed to by the address on
the stack referenced by "SelOffset".  Instead, however, the code uses the
32-bit physical address, "PhysAddr".  This will, in most cases, cause a
general protection fault when it is dereferenced.

To fix this problem, replace the line (in DDK v1.2 or earlier)

        les     si, Stk.PhysAddr

with the line

        les     si, Stk.SelOffset




!OTHER__________________________________**********
January 26, 1995
QUESTION: (Ref: G08)
1. What are the plans for AIX for the PowerPC?

2. Will there be a DDK for that, and if so when?


ANSWER:
We have no information on AIX for PowerPC.  But, you can call 1-800-879-2755
(AIX Software & Development) and order a couple of manuals that are available
to assist in writing device drivers.  The manual numbers are SC23-2593 for
AIX 4.1 and GG24-3629 for AIX 3.2

There is also an AIX primary support number, 1-800-237-5511.  There is a fee
for their service.

In addition, there is an AIX AUTO FAX number 1-800-426-4329.  You can order
documents that describe the various support services available.  The document
numbers are:  1537, 2464, 1760 and 1228.




!I/O____________________________________**********
January 26, 1995
QUESTION: (Ref: FZ7)
The DevHelp_PhysToUVirt code is incorrect.  After the completion of the call
to the assembly devhelp routine, there are lines of code to store es:bx in the
SelOffset parameter.  The offset in the stack used in the les instruction is
0x10, when it should be 0x06.


ANSWER:
This bug has been fixed in the DDK latest Release-DevCon DDK Version 1. Please
refer to the file DDKX86\SRC\DEV\DASD\DEVHELP\DHCALL2B.ASM -

After the initial declarations, the 32-bit physical address is loaded into
AX:BX, the length of the segment is loaded into CX, and the values of the
flags and tag are loaded into DH and SI respectively.  Following the call to
the DevHelp function, the virtual address is found in ES:BX.  The code
*SHOULD* put this virtual address into the space pointed to by the address on
the stack referenced by "SelOffset".  Instead, however, the code uses the
32-bit physical address, "PhysAddr".  This will, in most cases, cause a
general protection fault when it is dereferenced.

To fix this problem, replace the line

        les     si, Stk.PhysAddr

with the line

        les     si, Stk.SelOffset




!GENERAL_________________________________________**********
January 23, 1995
QUESTION: (Ref: FH7)
Here's my problem. I have a mouse driver which sends a double-click to
OS/2, by sending off two left buttons in sucession to the system. The
Presentation Manager recognizes these double-clicks and opens appropriate
folders, programs, etc, without a hitch. BUT -- when using either seamless
Win-OS/2, or Win-OS/2 full screen, there are lost clicks, and double-clicks
do not register (no matter WHAT the Win-OS/2 mouse control panel's double
click speed is changed to). This happens more in seamless Win-OS/2 (it fails
a greater percentage of the time than it succeeds), and less often in a
full-screen Win-OS/2 session.

Question is -- what is causing this?  Is it something I can work around?


ANSWER:
Your DDK came with an application for the OS/2 DDK/WIN-OS/2 Seamless
Supplement. This disk contains sources for WIN-OS/2 Mouse, WIN-OS/2 Serial &
WIN-OS/2 seamless VGA. The Mouse Code has the modifications that were made to
the Windows Mouse Driver for its adaptibility in an WIN-OS/2 Session.

If you do not have this application, call 1-800-633-8266 and ask them to fax
you a copy.

Please keep in mind that you will need to be a licensee of the Microsoft
Windows Version 3.0 AND version 3.1 DDK's to be able to use the supplement.




!I/O____________________________________**********
January 26, 1995
QUESTION: (Ref: FH2)
I have written a physical driver for a multi-port serial board our company
manufactures.  We now have a user that wants to use our ports from the
'Windows' window of OS/2.

I am aware that to access the ports from the DOS window of OS/2 a virtual
driver is required.  My question is ...  is there some sort of special driver
required to allow access to the ports from both OS/2 and the 'Windows' window?
Would the same virtual driver required by DOS do the job or is some sort of
special driver required to allow this operation to take place?

We currently have drivers that were specifically written for Windows 3.x and
drivers for DOS and a physical driver for OS/2.  I need to know if this is as
simple as a configuration issue, or what if any special driver is needed to
allow access through both paths.

Any information or resources you can point to, would be greatly appreciated.


ANSWER:
Your DDK came with an application for the OS/2 DDK/WIN-OS/2 Seamless
Supplement.  This Diskette contains the following:

    WIN-OS/2 Seamless VGA Code
    WIN-OS/2 Comm Code
    WIN-OS/2 Mouse Code

The WIN-OS/2 Comm Code help you build the Serial Communication Driver
(COMM.DRV) for WIN-OS/2.

COM.SYS is the Communication Driver for OS/2 and VCOM.SYS is the Driver in the
DOS Session under OS/2.  The Source Code for these are also contained in the
DDK.

If you do not have this application, call 1-800-633-8266 and ask them to fax
you a copy.

Please keep in mind that you will need to be a licensee of the Microsoft
Windows Version 3.0 AND version 3.1 DDK's to be able to use the supplement.




!BASE___________________________________**********
January 20, 1995
QUESTION: (Ref: G37)
I have a driver that uses the function DosQFileInfo at Init time.  In the older
toolkit I could resolve a call to this function at link time using
DOSCALLS.LIB.  With the Warp Toolkit I cannot find it anywhere.  Which library
is it in?


ANSWER:
OS/2 Warp is no longer shipping this file.  Equivalent functionality for this
library is contained in the OS2286.LIB that is available in the Developer's
Toolkit for OS/2 Warp Version 3.
ddk\lib\os2386.lib   (for 32 bit code)
ddk\lib\os2286.lib   (for 16 bit code)




!BASE___________________________________**********
January 20, 1995
QUESTION: (Ref: G23)
I am attempting to send a 32-bit (flat) pointer from an OS/2 application to the
PDD using the generic IOCtl request packet buffer, so that the device driver
may access process memory at interrupt time.  However, the system yields a
"General Protection Fault 0000" when I attempt to map the process memory to the
global (system) area.  According to the kernel debugger, the fault is occurring
in the DevHelp library, in the following code:

(CODE REMOVED FOR PRIVACY)

Specifically, the fault seems to occur at the line, "mov es:[si], eax", where
the es-register contains the value 0000h, which is reported by the debugger as
an "invalid selector".

I am not sure if I am implementing the DevHelp function call incorrectly, or if
I might be sending the flat address to the driver (within request packet IOCtl
buffer) improperly.


ANSWER:
1. Please Refer to APAR PJ15296.
Trap E occurs on using DevHelp_VMProcessToGlobal because the locked Global
Memory is marked with Page not present.  This problem was fixed in 6.644
OS2KRNL

2. The linear address supplied to VMProcessToGlobal must be page aligned.  The
call returns the global linear address in a variable whose address is to be
passed to the call.

To obtain the fix call (407)994-5544 and refer to APAR Pj15296.




!MULTIMEDIA_____________________________**********
January 18, 1995
QUESTION: (Ref: FZ8)
Is there a requirement for the use of a high resolution timer in an OS/2 audio
device driver that suports MIDI?  I know that high resolution timer support is
being added to the WARP+ version of OS/2.  This was discussed in the training
class in BOCA.  However, I am interested if there is a requirement for timing
at the device driver level or is all MIDI timing issues handled by the
application?


ANSWER:
All the Audio Boards that support MIDI have on Board Hi Resolution Timer and
hence the High Resolution Timer should be supported by the Audio Device Driver.
The MIDI timing issues are handled by the High Resolution Timer and not by the
application.

The High Resolution Timer is not available on WARP.  However, it should be
available in the next OS/2 Release.




!OTHER__________________________________**********
January 20, 1995
QUESTION: (Ref: FZ0)
I have just received your DDK and have attempted to load it under WARP.  I
specified that the entire CD be unpacked and loaded onto hard-drive H:, a 2.1
GByte SCSI.  I managed to hang the install process three times.  Each time it
hung WARP as well.  I have 130 MBytes of RAM and typically run in the mode
NOSWAP.  Any ideas?


ANSWER:
A conference call distinquished the problem as no timeout loop in the Adaptec
driver provided with WARP.  By power-cycling the drive the problem is
corrected.




!OTHER__________________________________**********
January 20, 1995
QUESTION: (Ref. FY6)
I am writing a driver that initializes some hardware and then can be removed.
How can I tell OS/2 to remove my driver at init time without asking the user to
press a key to continue?


ANSWER:
After the Initialization you could use the following code:

           rp -> s.InitExit.finalCS = (OFF) 0;
           rp -> s.InitExit.finalDS = (OFF) 0;
           return (RPDONE);

This requires the User to press Enter to Continue.  However, the memory
associated with this driver is released.




!MULTIMEDIA_____________________________**********
January 20, 1995
QUESTION: (Ref. FY5)
I have a short driver that inits my soundcard so the mitsumi driver can access
the drive, but it has to run BEFORE the mitsumi driver.  I have to create a
BASEDEV type driver.  How is this different from a DRIVER type driver?


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

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

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

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

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

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

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




!VIDEO__________________________________**********
January 20, 1995
QUESTION: (Ref: FY0)
When using Ctrl-Alt-Del to reboot the system while in high-resolution display
mode, the display does not reset to text mode.  Proprietary I/O register
commands are required to accomplish this, as we are developing a driver for our
own graphics accelerator chip.  Does the system provide an opportunity for the
PM and/or WIN-OS2 display drivers to be notified of this and other BIOS level
requests, or can the proprietary I/O commands be registered with the system to
enable it to reset the video mode directly?


ANSWER:
There is a DosShutdown API, but I don't think that this API causes a
VioSetMode, since that would change the desktop from the PM screen with the
popup message, which I've never witnessed.

Why can't you make your BIOS reset the Command Registers (problematic
registers) first as part of the POST and every mode set?  That is the true
solution to the problem, as running real windows & doing a CTRL-ALT-DEL will
not get a good reset even if we do manage to find an entry point to perform the
reset in OS/2.

FOLLOWUP QUESTION:
Without visibility to the PM shutdown procedure, we cannot determine if it is
possible to register the I/O commands required to restore text mode when the
user presses Ctrl-Alt-Del after a shutdown.  The module SVGA.C provides the
capability to create an SVGA.PMI file with functions specific to a proprietary
chipset, including a `SetVideoMode' procedure.

1. Is the Ctrl-Alt-Del handled by a PM or ABIOS function that utilizes such an
internal procedure, or is the video mode reset handled by the system BIOS?

2. Is there a function or process that can be executed during the boot cycle or
CONFIG.SYS processing that uses such an internal process that can be modified
to include the I/O commands specific to our chipset?

Our chipset does not include any Option ROM that would be initialized during a
warm boot.  We have not licensed the source code for the VGA BIOS in order to
add proprietary register commands to the boot procedure.  The VGA/graphics mode
bit is reset only at power on, so the user would have to power off or perform a
CPU NMI reset.

FOLLOWUP ANSWER:
You should have a Ring0 physical device driver installed.  The driver has to
handle the strategy routine 1C (hex), which is called during shutdown.  Refer
to the PDD Ref.Manual, Section on Device Attribute & PDD Strategy Commands -
1CH.  There is no architected way of passing the control to any other driver
during the shutdown.




!OTHER__________________________________**********
January 20, 1995
QUESTION: (Ref: FX7)
Q1. In Debugo, after I copy into the Clipboard, how can I print the info or
    save it in a file?

Q2. I am writing an Adapter Device Driver (ADD) for a parallel port based IDE
    hard disk.  I was using the IBMS506 ADD that is provided on the DDK as a
    template for my ADD.  I want to print info from within the ADD to help in
    debugging.  How can I print from with the ADD?

Q3. DevHlp_Save_Message can **only** be used during Init mode.  If I want to
    print from Kernal mode, is there a way?  Also, is there a way to save data
    to a file from Kernal mode?

A1. Use the Debugo in the Edit-Review Mode.  Mark the specified area and then
    do a Edit-Copy [or Control - Insert] to copy the Marked Text onto the PM
    ClipBoard.  Next use a PM Editor to Paste the Marked Text onto a Temporary
    File which could also be used to Print.

A2. The DevHlp_Save_Message displays a Message from a Base Physical Device
    Driver on the System Console.  This is implemented in the TTYWrite Routine
    in DDKX86\SRC\DEV\DASD\IBM\IBM1S506\S506INIT.C

A3. You could refer to the code in COMMDBG.C in the PAS-16 audio driver on the
    DDK.  It provides "printf" similar function using the serial port.

    - Limitations:  Switching COM:  ports requires re-compile and debug
      terminal connection must be 9600 bps.
    - Location:  \ddkx86\mmos2\samples\pastk\.

    You could also use dprintf function defined in
    \ddkx86\src\dev\dasd\ibm\ibm2scsi\dprintf.asm.  Also see scsiadd.h in the
    same directory, where different flavors of INFMSG are defined.  INFMSG are
    nothing but routines calling dprintf.

    Another alternative for Basedev and Post Init (Ring 0) would be to write a
    Ring 3 Daemon that talks to your driver via Ioctl to get the Message to
    display.  The Ring 3 Daemon could be used to save data to a file from the
    ADD's kernel mode.




!BASE___________________________________**********
January 20, 1995
QUESTION: (Ref: FX1)
I have a IOCTL Data buffer locking problem (specifically DevHelp_Lock)
DevHelp_Lock is failing to lock a 62,000 byte buffer intermittently.

The IOCTL section of our strategy routine accepts large data buffers from some
IOCTL functions.  The device driver locks the data buffer (and parameter
buffer) using the DevHelp_Lock function as shown in the code fragment below.
We have had an intermittent problem which causes the DevHelp_Lock routine to
fail on a 62,000 byte buffer.  The buffer resides in the static data segment
of the 32 bit process which calls DosDevIOCTL.

I believe that the problem has to do with the alignment of the 62,000 byte
buffer, because the problem only seems to occur when the buffer location,
within the 32 bit data segment, is modified.

Do we have to do some kind of 16:16 virtual address normalization before
supplying the data buffer address to the DevHelp_Lock routine?

FAILURE SPECIFICS:

At the 32 bit process level the 0:32 virtual address of the IOCTL parameter
buffer is 0xC85EA and the 0:32 virtual address of the IOCTL data buffer is
0xA9C22.  The process level segment registers are CS=0x5B, DS=SS=0x53,
FS=0x150B, and GS=0.

At the device driver strategy level the parameter buffer 16:16 virtual address
is 0x67:0x85EA and the data buffer 16:16 virtual address is 0x2C7:0xC22.


Also, will DevHelp_Lock always fail for IOCTL buffers not allocated from TILED
memory, or will it just fail intermittently?
(customer code removed for security)


ANSWER:
1. By default, when DosDevIOCtl passes an address to the Device Driver, it
passes an address in the form of a temporary selector.  This selector is valid
only for the duration of the call and cannot be used to lock the memory using
the DevHlp_Lock.  If you need to lock this memory, the calling program must
use the DosAllocMem function with the object title ( OBJ_TILE ) bit set.  If
you pass a pointer to this memory in the call to DosDevIOCtl, the device
driver can use the DevHlp_Lock to lock this memory.

2. A 32 bit virtual memory is allocated for an application from the 512 MB
tiled memory space by the OS/2 kernel.  This address can be converted into an
equivalent sel:off pair by using macros 'FlatToSel' and 'SelToFlat' (available
in \ddk\inc\devhlp.inc).  Using this macro the 32 bit virtual address of data
buffer being 0xA9C22, its sel:off equivalent comes out to be 57:9C22.  The
sel:off for the data buffer in your case comes out to be 2C7:C22 which is
erroneous.  We advise you to check your code.


3. If the Memory that is allocated is in the first 512MB of the Virtual
Address Space,with 16-bit selectors mapping the memory object,you should have
no problems using the DevHelp_Lock.  The 16-bit selectors are allocated to map
the 32-bit object at 64KB boundaries if the OBJ_TILE is used in DosAllocMem.
If this is not used there is a possibility the address you are using might
cross over to the next 64K Selector.  You could refer to "The Design of OS/2"
- Deitel & Kogan ,Chapter on Compatibility,Section on LDT Tiling.




!I/O____________________________________**********
January 20, 1995
QUESTION: (Ref: FW8)
I am trying to work with a Point-of-Sale type keyboard that controls a card
reader, bar code scanner, customer display and a cash drawer.  This involves
sending commands to the keyboard via the keyboard port and receiving
keystroke/scanner/card reader data from the same port (both sides sending data
on the same wire, possibly at the same time).  There must be some kind of
arbitration so commands from the PC and scan codes from the keyboard don't
collide.

The POS keyboard in question the "Series 500 POS keyboard" made by "Ultimate
Technology Corporation" (phone# 716-924-9500).  All the scan codes received
from the POS keyboard are standard PC scan codes and I am having no trouble
processing them.  I have no trouble parsing the data from the
keyboard/scanner/reader.  The thing that they require is for me to send
commands TO the keyboard through the keyboard port in order to display data on
the customer display.  The commands consist of a series of bytes sent to the
keyboard, the content of which is not important except to say that any random
byte value may be used (00-FF).  I noticed that there is no provision in the
standard keyboard device driver or in the os/2 API to send random bytes of
data out the keyboard port (except whatever it takes to turn on some LEDs).

There is no h/w manual for the POS keyboard that shows how this is done.  They
told me over the phone to monitor input port 64h and after the byte value
returned shows bit 3 set, write the byte to be transmitted out port 60h.  This
works fine except when the keyboard and the PC both try to transmit at the
same time.  It should be expected that data would be lost if two sides attempt
to transmit data on the same wire at the same time without some kind of mutual
exclusion.

Is there a standard proceedure for one side to claim the line and lock out the
other side until it is done sending?

The POS keyboard makers say the "hardware" takes care of everything and they
obey the "standard" rules for bi-directional transmission between the PC and
any keyboard but seem reluctant to tell me what these rules are.  If there is
no keyboard device driver that uses the "standard" then I must either write
one or attach the customer display somewhere else on the PC.  But first, I
must find out what rules govern bi-directional transmission between the PC and
a keyboard (possibly an extension of the rules that allow the PC to turn on
LEDs on a keyboard).

Is there a standard?  If so, what are the rules?  If there is no standard here
we may have to make one up.


ANSWER:
Data should be written to the controller input buffer only if the input-
buffer-full (bit 1) in the Controller Status Register (address hex 0064) is 0.
The Input Buffer Full Bit(bit 1) 0 implies, that no new data has been sent by
the KeyBoard and a Command could be sent to the KeyBoard.  This takes care of
the Arbitration.

Monitor bit 1 of the Controller Status Register(hex 0064).  If this Bit is 0,
you could go ahead and write the KeyBoard Command into the Command/Status Port
(hex 0064).

To ensure that the Buffer Data is valid,disable the KeyBoard & the Auxiliary
Devices before initiating a command that causes the controller to generate
output at Port 60.

You could use the following Controller Commands :

    AD - Disable KeyBoard Interface
    AE - Enable KeyBoard Interface
    A7 - Disable Auxiliary Interface
    A8 - Enable Auxiliary Interface

The above are documented in the PS/2 Hardware Interface Technical Reference
Manual - KeyBoard & Auxiliary Device Controller.




!VIDEO__________________________________**********
January 20, 1995
QUESTION: (Ref: FW5)
We would like to know the rules of the algorithm used by GRE to establish the
clip rectangles on the PM screen for when rendering is done on the PM desktop.

In the example below, windows A, B and C are on top of window D.  This causes
window D to be broken into multiple visible regions.  QUESTION-> What is the
algorithm or set of rules used in GRE for generating the list of these visible
(clipping) regions?

We are building code for some hardware which we would like to reuse between
the Windows and OS/2 environments.  In order to do that, we must know the
rules used to generate this clipping region list in both environments.  We
know that Windows uses a top-to-bottom, left-to-right algorithm and guarantees
that these regions will not overlap.  This is documented in the MS and Intel
Display Control Interface (DCI) document available in the DCI toolkit on
CompUServe. (DCI is sort-of like EnDive)

An example from the Windows world:

I hope these crude line graphics don't get messed up in transmission.  View
with a fixed font to get better results.
          -----
  --------| A |  -- U (top of D)
  |       -----  -- V (bottom of A)
-----  D     |  --- W (top of B)
| B |  ----- |  --- X (top of C)
|   |  | C | |
-----  ----- |  --- Y (bottom of B and C)
  |          |
  ------------  --- Z (bottom of D)

This particular example generates 6 visible (clipping) regions for D in
Windows.

The first region is from the left edge of D to the left edge of A, from U to
V.

The next region is from the left edge of D to the right edge of D, from V to
W.

The next region is from the right edge of B to the right edge of D, from W to
X.

The next region is from the right edge of B to the left edge of C, from X to
Y.

The next region is from the right edge of C to the right edge of D, from X to
Y.

The last region is from the left edge of D to the right edge of D, from Y to
Z.


ANSWER:
The XGA/8514/S3 DDK PM display driver keeps 4 clip regions cached in the DC
data structure.  If there are more then 4 clips it will flag this fact and
call the engine to obtain all of the clips when they are needed to draw.
Refer to the following files in the DDK :  ddkx86\src\pmvideo\32bit\eddaclip.c
& pixblt.c.  The Cohen Sutherland Clipping Algorithm is used and a point is
deemed to be inside the rectangle if it lies on the edge.  Refer to the file
eddgcorr.c in the DevCon DDK Version 1.




!VIDEO__________________________________**********
January 20, 1995
QUESTION: (Ref: FV5)
I am trying to find a way to output a debugging string from a seamless driver
to the debug terminal while running the kernel debugger.

I searched for "debug" under the Display DeviceDriver Reference, but I only
found information about how to do that for a PM driver, which involves calling
DebugOuput, which in a macro defined in pmwinx.h as

    #define DebugOutput Debug32Output

This is, I assume, a function that is inside one of the OS/2 libraries that
gets linked to the PM driver.

In the seamless sample provided on the DUDE, I can see something like

  ifdef SM_DEBUG
        push    SEG    escape_init
        push    OFFSET escape_init
        call    DebugOut
  endif

But how is this function DebugOut implemented?

An example will be greately appreciated.


ANSWER:
You will need the Optionally Available Diskette containing the Microsoft
Window 3.1 DDK Modified Code for:

          WIN-OS/2 Seamless VGA
          WIN-OS/2 Comm
          WIN-OS/2 Mouse

If you need the ordering form for this optional diskette, we can send it to
you.


DebugOut is a FAR Procedure defined in :
WINOS231\DRIVERS\DISPLAY\4PLANE\DEBUG.ASM




!VIDEO__________________________________**********
January 20, 1995
QUESTION: (Ref: FU9)
Q1.  Can anyone give me information about DIVE or ENDIVE.  I hear it allows
for simple framebuffer video drivers for Warp.  Is this true?

A1.  The new API Set called DIVE will provide a new method of fast blitting of
image data, support for color depth conversion, display hardware bank
switching, visible region clipping and sretch blitting.  It will also provide
a pointer to the frame buffer.

The Developer's Connection DDK, version 1.0 has information concerning Endive
within the presentation Manager Section.  I can provide you with coding
samples if you are interested.

DIVE is part of the OS/2 Warp Version 3 Toolkit (available through the
Developer's Connection Volume 6).  The online documentation that is part of
the Toolkit (Multimedia Programming Ref.  and Multimedia Application
Programming Guide) contains the documentation on DIVE.
==============================================================================

Q2.  Also, does Warp have a concept of multiple screens?  We have a display
card that is capable of driving two monitors simultaneously.  I've written a
Windows driver for it that runs on both screens, but I have to make Windows
believe there is really only one physical screen.  (I split all graphics calls
between the two screens in my driver.)  I was wondering if WARP has a built-in
mechanism for OS/2 to run on multiple screens similar to X and MAC platforms.
Or (when we get around to developing a Warp driver) will I have to fake it out
also by making it think there is only one physical screen?

A2.  Within the current PM driver model, there is no mechanism of registering
multiple drivers to handle a virtual desktop.  So, the distribution of
coordinates has to be done within the driver, just as is in Windows.

However, we have a new PM model in working which is already implemented on the
OS/2 for Power PC and will be ported back to Warp (Intel OS/2) some time next
year.  This model should support logical division and multiple drivers sharing
the virtual desktop.  At his time we do not have any drivers available of such
nature to show this architecture.

Please contact Weldon Adair, our Video Device Driver expert, at (407)
443-4206.  Weldon can provide information on our video Power PC classes and
the Power PC loaner program, if you are interested.




!OTHER__________________________________**********
January 20, 1995
QUESTION: (Ref: FS7)
Has there been a change in the way Warp Drives app interacts with an IFS?  I
notice problems when sending back lots of "level 3" info in response to
findfirst and findfromname.  Seems that sending lots of EA's causes trouble.
This IFS works fine (EA's and all) in 2.1.

Also, I notice a "new" pattern in Warp, when opening a directory in Drives, of
three successive find sequences.  Why three?  Has there been a change?  P.S.
It works well when I return no EA's, just a 4 for cbList.


ANSWER:
As far as I know, there is no change to the specific processing of the EA
requests.  My IFSs continue to work unchanged.  You must be aware of a design
exposure on 32 bit FindFirst/FromName.  As the buffer returned on the call is
NOT the format the client application gets, the buffer is REFORMATTED.  As
such, it is POSSIBLE that with a full retune buffer, that one of the file
entries you return will NOT be passed to the client, and on the NEXT
FindFromName, you will be told to restart somewhere in the PREVIOUS return
data.

Sorry we can't be of much help on this one but you really need to check with
our DAP group (407-982-6408).




!BASE___________________________________**********
January 20, 1995
QUESTION: (Ref: FS0)
I have a curious situation with a device driver in which a call to the device
driver to do a 'read' occasionally returns a 'permission denied' error, even
though a 'open' on the device driver has just previously succeeded.

I have written the device driver, but have not sent the source code because
the error is returned before the device is called to perform the read.

  unsigned bytesread2;
  int fh;
  int retu;
  int *adBufferPtr;

  adBufferPtr=malloc (0X3000); /*allocate 12K bytes*/
  if(_dos_open("CHUCK$  ",O_RDWR,&fh))
  {
       printf("open failed \n");
       perror("open");
  }
  retu=_dos_read(fh,adBufferPtr,0xE10,&bytesread2);
  if(retu!=0)
  {
     printf("read failed \nreturn = %d\n",retu);
     perror("read");
  }
  if(_dos_close(fh))
  {
       printf("close failed \n");
       perror("close");
  }



When this code executes, the open will always perform without returning an
error.  However, once in a while, the read will return a 'permission denied'
WITHOUT EVEN GETTING TO THE DEVICE DRIVER.  OS/2 is intercepting the call to
the device driver and stopping it with an error before the device driver is
called.


ANSWER:
We do not have any documentation on "_dos_open" & "_dos_read" that you are
using.  Our response is with respect to DosOpen & DosRead which are supported
on OS/2 2.x

a) Refer to the documentation on Sharing & Access Mode Flags in DosOpen(in the
Control Program Programming Reference Manual).If the Flags are not set
appropriately you could get a Permission Denied,if the previous process which
has done the DosOpen and has not Closed the transaction.

b) Have you checked the integrity of the file system?  Some of the Extended
Attributes in the root partition could have been damaged.

c) You could put the read into a loop (say 3 times with a small delay between
each attempt) and check if the error still persists.

d) Check if some other process is opening this driver when you are testing
this code.  Note this could be some backup program or a daemon.




!OTHER__________________________________**********
January 12, 1995
QUESTION: (Ref: G06)
I don't know if this the right place but perhaps you can point me to the right
place if it isn't.

I need to write some device drivers for AIX on an RS6000, I have the machine
but no documentation on the OS, no DDK and no SDK (also have to port a GUI
utility to MOTIF.

Do you know where I can get the documentation?


ANSWER:
You can call 1-800-879-2755 (AIX Software & Development) and order a couple of
manuals that are available to assist in writing device drivers.  The manual
numbers are SC23-2593 for AIX 4.1 and GG24-3629 for AIX 3.2

There is also an AIX primary support number, 1-800-237-5511.  There is a fee
for their service.

In addition, there is an AIX AUTO FAX number 1-800-426-4329.  You can order
documents that describe the various support services available.  The document
numbers are:  1537, 2464, 1760 and 1228.




!VIDEO__________________________________**********
January 12, 1995
QUESTION: (Ref: FY7)
I have implemented eddh_PMImageData for the Number Nine I-128 graphics
accelerator, and the results I'm getting leave me baffled.

As I understand it, eddh_PMImageData transfers a single scanline of monochrome
image data to the screen.  When used to transfer a rectangular monochrome
bitmap, it is called repeatedly by the graphics engine:  one call for each
scanline.

Well, my implementation is drawing its scan correctly, but when I run an
application that employs GpiImageData to draw to the screen, my driver function
is NOT called repeatedly.  It is called just once by the engine to draw the
first scanline, and is then not called again until the next image.

I have checked eddb_ImageData, the entry point called by the GRE, and this
higher-level function, which calls my eddh_PMImageData, is returning just fine
to its caller.

What could I have done within the driver (or elsewhere) that might cause the
graphics engine to call eddb_ImageData just once for each bitmap to be
transferred?!


ANSWER:
GpiImage cannot be used while there is an open area bracket or while there is
an open path bracket.  Confirm you are not operating under these conditions.

You can also cross check your code with eddh_PMImageData in
\ddk\src\pmvideo\32bit\eddimag.asm.

GreImageData is supposed to be called multiple times for each call to GpiImage
(once for each scan line in the monochrome bitmap).




!BASE___________________________________**********
January 12, 1995
QUESTION: (Ref: FW7)
We are experiencing problems loading our OS/2 physical device driver in OS/2
2.1.  The driver works fine with OS/2 2.11 and Warp.  Our driver is in the "LX"
exe file format because it has both 16-bit and flat segments.  The problem we
are seeing with OS/2 2.1 is that it is only loading the first 32K of our flat
code segment and discarding the rest.  The problem only happens if I load the
driver from the hard drive.  If the driver is loaded from a floppy drive, it
works fine.  I have stepped though the kernel's loader code and this is the
information I have found so far:

Inside the function _ldrOpenNewExe each segment is read from disk and copied
into the buffer that was allocated for that semgent.  The loader is allocating
the correct buffer size.  After copying the first two 16-bit segments
correctly, it then gets to my 33K flat code segment.  It checks the map size of
the flat segment object and compares it to 8. Since is it greater than 8 (9),
it will then copy the first 32K from the buffer it read from disk into the
buffer it allocated for this segment.  It then frees the first buffer.  It then
checks the exe header's module flags that the loader has changed considerably
by this point.  Based on the value of two bits (0x1000 and 0x10000) it will
determine if it will continue copying data.  If I load the driver from the hard
disk, bit 0x1000 will be set, and this segment will only be partially loaded.
This bit will be set if _IOGetMediaInfo returns with bit 0x20 set (when the
driver is loaded from the hard drive it returns 0x21).

My question is:  is there any way to work around this OS/2 2.1 limitation and
still have a valid LX device driver?  Is there any flags I can set in my exe
header to convince the loader that it is OK to load segments that are larger
than 32K from a file that is on the hard drive?


ANSWER:
There are two known problems loading physical device drivers that have been
linked with LINK386.  One has to do with zero-filled pages and only occurs on
486 systems.  The other problem is that only the first 32K of code is loaded
for each segment.  Both problems have been fixed by OS/2 developers.

This is a kernel fix and you will have to contact the OS/2 Support for a
Service Pack.




!BASE___________________________________**********
January 12, 1995
QUESTION: (Ref: FV6)
How can I allocate memory in a device driver such that the memory is guaranteed
not to cross a 64KB tiled boundary?  I need to do this in order to use DMA on
an ISA bus machine.  The memory needs to be entirely within a 64KB DMA page,
and it must be below the 16MB physical address point as well.

I am using DevHlp_VMAlloc.  The docs indicate that it will give contiguous,
fixed memory below 16MB (three criteria I do need), but it returns memory with
a 4KB page physical address granularity.  I can allocate 8KB and have it end up
at 0x00??f000, for instance, which causes the low 16 bits to wrap past zero.
That doesn't work on the DMA controller.

DevHlp_AllocPhys won't work because it only allows allocation above or below
1MB.  I need that point to be 16MB.  Doing a tiled malloc in the app and
passing the buffer to the driver for locking won't work either, as the tiled
malloc library function cannot limit itself to 16MB or lower.

My alternative is to continue allocating blocks until I get a good one, then
free up the wasted blocks.  This is a fair amount of work, though.  Isn't there
some mechanism I can use to get TILED memory in the DD?  I'm kind of desperate
here!

I have also tried allocating the memory in my DLL and using VMLock with flags =
0x1f and generating a PageList.  The physical address returned into the
pagelist is the same as that returned by the LinToGDTSelector, VirtToPhys
sequence.  I cannot find ANY way to allocate this physically-tiled (DMA
page-aligned) memory!


ANSWER:
1. Sample Code for allocating the DMA Buffer is in the DDK in
"DDKX86\MMOS2\MMTOOLKT\SAMPLES\AUDIODD\AUDIODD.C".  The function is
AllocDMABuffer and the example uses DevHelp_AllocPhys.

   The sequence is as follows:
       DevHelp_AllocPhys
       DevHelp_PhysToGDTSelector
       DevHelp_FreePhys

The physical memory is always allocated below 16 MB.  AllocPhys only requires
that you specify if the memory is to be allocated below 1MB or above 1MB.
Select the Above 1MB Flag for AllocPhys.

You could also refer to the example in "DDKX86\SRC\DEV\DASD\IBM\
IBM2FLPY\FL2ENTRY.C"

2. To do a DMA < 16MB, we need to indicate that the virtual pages be locked
contigiously in an area that does not cross a 64KB phys boundary and is also
below 16MB.

There is no documented way in either AllocPhys, Lock, VMAlloc or VMLock to
achieve this.  An alternative would be to allocate fixed and contigous 2N bytes
in the < 16MB region and use the portion of the memory that does not overlap a
64KB boundary.




!STORAGE________________________________**********
January 12, 1995
QUESTION: (Ref: FV0)
How can I determine the last physical drive from within my VDD?


ANSWER:
The VDHPhysicalDisk Funtion returns information about the Partitionable Disks.
You could use the Function with the VDHPHYD_GET_DISKS parameter which would
return the total number of Partitionable Disks.

if (!VDHPhysicalDisk(VDHPHYD_GET_DISKS,
                      &Number_Physical_Disks,
                      sizeof(Number_Physical_Disks),
                      NULL,
                      NULL) ) Error();

Sample Code for this implementation is available on DDK;
DDKX86\SRC\VDEV\VDSK\VDSKINT.C




!I/O____________________________________**********
January 12, 1995
QUESTION: (Ref: FU7)
I'm trying to read the Mouse Event Queue (catagory 7; function 0x63) and I'm
getting an error #22 (Bad Command).  I'm writing a normal PM EXE and I'm having
no luck.  I've checked the Device Drivers Developer CD-ROM to insure that I'm
making the call properly, and I seem to be.  What might I possibly be doing
wrong?


ANSWER:
If the Single Queue Mode is active for the session, then a Bad Command Error is
returned.  The error is because you are invoking the IOCtl from a PM Session.
Use the Read Mouse Event Queue IOCtl in the Full Screen OS/2 Session - you
should not receive the Bad Command Error.

The Keyboard Driver interacts with the SINGLEQ$ (Single Queue) Driver when
KeyStrokes need to be passed to the PM Screen Group.  SINGLEQ$ is a Device
Driver and is not contained in the DDK.  This is an Internal Interface which is
not documented and is liable to change.

All events go into a single queue.  The application with focus gets to pick
events from the queue.

Ref: Chapter 12, PM programming reference vol - iii, section on
      WM_MOUSEMOVE Event.

To get the Mouse Events in a PM Session, you could seek assistance from the
Developers Assistance Program (DAP) at 407-982-6408.




!BASE___________________________________**********
January 12, 1995
QUESTION: (Ref: FU1)
In the INIT section I want to allocate system buffers for the input (JPEG) and
output (SVGA) images.  The purpose is to validate that the board is working
properly.  Every time I issue a PhysToUVirt() the system locks.  Can you give
me an example of how to allocate and access these buffers?


ANSWER:
The Selector created by PhysToUVirt() does not represent a normal memory
segment but is a fabricated segment for private use between a Device Driver and
an Application.  Data within such segment cannot be passed on System Calls and
may only be used by the receiving Application to fetch Data Variables.  You
could use the PhysToVirt DevHlp.  The mappings are limited to 64KB and the
virtual mappings produced by PhysToVirt is invalidated by calls to the DevHlp
services PageListToLin & PhysToVirt.  Another alternative to get around these
limitations would be to use VMAlloc.




!BASE___________________________________**********
January 12, 1995
QUESTION: (Ref: FS5)
I am working on a Character Device Driver (in Assembler) and I want to use a
Character Device Monitor application.  The Physical Device Driver Reference
manual keeps talking about the DosMonXXX functions and to refer to the Control
Programming reference but I can not find them anywhere.

1. What gives?  Are these C functions that I can use?

2. Are they really talking about the DosIOctl function?


ANSWER:
1. The DosMonxxx APIs are documented in the Control Program Programming
Reference for OS/2 v1.3.  They could be used both from Assembly Language as
well as from your C Program.  The DosMonxxx Calls still exist in the 16 bit
form in OS/2 2.x.  If you have a 16 bit application just code it the way you
did in OS/2 1.x

2. The DosMonReg does generate an IOCtl Request for the application, as is
documented in the I/O Device Driver Reference Manual for the Parallel Port.
However the reference to DosMonxxx calls refers to the same entity and not the
DosDevIOCtl as you have indicated.




!VIDEO__________________________________**********
January 12, 1995
QUESTION: (Ref: FR1)
1. I need the System VIO fonts (vio0610c.fnt, etc.)  in a .FON file format
   (Yes, .FON) for OS/2 version 1.3.

2. I know that they currently are in the DSPRES.DLL file under 2.1, but I
   need them split out into a .FON file for OS/2 1.3.

3. Are the System VIO fonts 32 bit only?


ANSWER:
You will definately need the 1.3 Toolkit tools to compile for 1.3.
Additionally, 1.3 only supported the PM131 character set, and 2.0 introduced
an enhanced FNT file format, so they may not be accessible at all for 1.3
tools without writing a program to change the font file format around.  For
2.0 access, you will need a new RC as described below.  The LINK386 and 2.0 RC
compiler should be fine.


1. You can create .FON files for OS/2 1.3 if you have the .FNT font files.  In
   order to create a 1.3 .FON file, you need to have the 1.3 resource compiler
   and linker.  LINK386 should work.  However, it would be better use the 1.3
   linker to be sure.  The procedure is as follows:

    (1) Create a stub source file.  Compile and link using the 1.3 tools and
        toolkit.  It will create a 1.3 stub module.

    (2) Create a RC file which describes the .FNT files you are putting.  The
        type-id must be 7 for font.  Compile using the 1.3 resource compiler.

    (3) Attach the binary resource created by (2) to the stub module created by
        (1).


2. The FNT files for DSPRES.DLL are shipped with the DDK for display driver
   developers who need to modify/expand on them.  If you have the FNT files,
   you can create the FON file using the way of (1).

3. No.
