This is file: 04_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__________________________________**********
April 30, 1995
QUESTION:  (Ref: H38)
I read ddsc_des.txt and (contents of) newddk.zip and I still have a question.
Neither document specifically states that a WARP compatible assembler is
included in the DDK upgrade to my DevCon subscription.  Is a WARP compatible
assembler included in the DDK upgrade to my DevCon subscription?  If not, is a
standard API library included that I can link into my CSet++ producted
objects?


ANSWER:
MASM 5.10A and MASM 6.00 are Warp Compatible.  MASM 5.10A is included in the
DDK.

There are no new assemblers with DevCon DDK Version 1. OS2386.LIB and the
other libraries are Warp level and you could use them for your Warp API calls.
The Warp level libraries are available in DevCon DDK Version 1 and this could
be used to link to your CSet++ produced objects.




!STORAGE________________________________**********
April 30, 1995
QUESTION:  (Ref: H26)
I am writing an IDE CD-ROM driver for our Parallel Port (Printer) to IDE
adapter.  While looking at the ATAPI CD-ROM source code, I noticed that the
filter driver relies on the IDE hard drive driver to setup the unit type as
UIB_TYPE_ATAPI.  However, the current IBM1S506.ADD does not take care of an
IDE CD-ROM with ATAPI protocol.

Q1. Is there a new IBM1S506.ADD which supports an IDE CD-ROM?

A1. The ATAPI Support (in the ST506 Code) is planned to be available in the
next DDK Release.  The current release is Devcon DDK 1.0.
==============================================================================

Q2. How do I install my IDE CD-ROM to the secondary IDE controller configured
at IO address 170 hex and IRQ 15?

A2. The installation is Automatic if you use the code in the DDK.
==============================================================================

Q3. If the current IDE hard disk driver does not support IDE CD-ROMs, do you
think that the IDE CD-ROM should be impletemented as an ADD instead of a
filter driver?

A3. The Warp level IDE hard disk driver does support IDE - CDROM, hence you
are better off implementing the FILTER.




!GENERAL________________________________**********
April 30, 1995
QUESTION: (Ref: H21)
I have a working version of device driver in which I used code and library
calls from Steve Mastriani's book and library.  It work's well in text mode
but I need to allow a GUI written in Borland C version 2.0 access to the
driver.

The program compiles and links fine.  At run time the DLL loads then the error
occurs when the program calls the function from the loaded DLL.  We receive
the following error message:

SYS2070 "system could not demand load the application segment MSCTEST msc_sub
in error" (also references SYS127 error)

Borland C ver 2.0 does not support Far calls in OS/2, MSC6.0 does.

BORLANDC CODE CALLS DLL FUNCTION msc_sub(int,int)
---------------------------------------------------------------------------
// listing for msctestm.c
#define INCL_DOSERRORS
#define INCL_DOS
#include <os2.h>
#include <stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <string.h>
#include <process.h>
extern void _export _pascal msc_sub(int, int);    // make the compiler and
                                                     linker happy
void main(void)
{
   int x=123, y=456;
   PFN *ppfn;
   HMODULE hDLLModule;
   CHAR  szFailBuff [100];
   // Load the controls dynamic link library
   if (DosLoadModule (szFailBuff, sizeof(szFailBuff), "STD1553",&hDLLModule))
           printf("Couldn't load DLL\n");
   else
           printf("Loaded DLL\n");         //  we get this message
   msc_sub(x, y);                          //  this is were it fails
   DosFreeModule (hDLLModule);
}
--------------------------------------------------------------------------
// listing for msctestm.def  for borland c project
NAME          MSCTEST
DESCRIPTION   'Homina'
PROTMODE
HEAPSIZE      4096
STACKSIZE     16384
IMPORTS
        STD1553.msc_sub
SEGMENTS
                _IO_TEXT        IOPL
--------------------------------------------------------------------------
//listing for STD1553.c for MSC6 dll
#include <stdio.h>
#include <conio.h>
void _export _loadds  msc_sub( int x, int y )       // required for DLL
{
    printf("In da sub, x=%d  y=%d  x+y=%d\n", x, y,(x+y));
}
---------------------------------------------------------------------------
//listing for STD1553.def module for MSC6 dll

LIBRARY STD1553 INITINSTANCE
DATA MULTIPLE


ANSWER:
After loading the DLL, the address of function should be obtained using
DosQueryProcAddr and then call the function. In your program the address of
the routine msc_sub() is not extracted, this could be the problem.

After the line > printf("Loaded DLL\n");
include >>>>>>  ulerr = DosQueryProcAddr(hDLLModule,
                                                            0,
                                                            "msc_sub",
                                                            (PFN *) &msc_sub);

Ref : Application Design Guide Ch - 5, section on linking at run time.

You should declare the exported function as Far Pascal (#defined as EXPENTRY)
Ex : void EXPENTRY loadds msc_sub(.....)
       {
               .
               .
               .
       }

In the application program, declare the imported function as

 void APIENTRY msc_sub(.....)




!I/O____________________________________**********
April 30, 1995
QUESTION: (Ref: H18)
I have modified the ST506 driver to allow 32 bit I/O xfers on the first
controller, among other things.  The driver works fine sometimes, other times
it does not.  When it does not work, it gets stuck when it is trying to run
pmshell--the blue screen comes up that comes up before the icons show up, then
it goes dead and the debugger diplays an error saying:

     DelayHardError  SYS 3175:  4 string(s):
     Pid 0003  Tid 0001 Slot 0008  HobMTE 00f7
     C:\OS2\PMSHELL.EXE

This error does not always happen, and when the system is able to come up, it
seems to operate normally.

I have modified the addservc.c file so that if the xfer is on the second
controller, it uses the original 16 bit code, but if it is on the first
controller, it does 32 bit transfers.  Because the S/G segment might not be
double word aligned, I figured there were six cases to take care of at the end
of each iteration:  the S/G might be off by one, two or three bytes, and each
of these might be input or output.  I handled these cases in much the same way
the original code handles the case of being one by te off.  If it was input, I
went ahead and transferred in a whole doubleword, and held the value in a
variable.  I then put the lowest byte where the pSrcDst was pointing, and
incremented the pointer.  If it was off by more than one byte, I moved the
next byte to where pSrcDst was pointing, and so on.  Then in the next
iteration of the loop, I transferred the byte(s) remaining to the new pSrcDst.
In each case, I incremented the ppSrcDst by the same amount as pSrcDst, and I
incremented totalxfer by two wor ds, and decremented xfercur at the top of the
next iteration by the correct number of bytes.  Output was basically the
reverse; I filled a variable with the byte(s) left to be transferred, then on
the next iteration of the loop, I filled up the rest of th e doubleword and
transferred it.

I have traced through the execution of the code handling these cases, and the
xfers seem to be taking place correctly; the data seems to be ending up where
I want it.  I would like to ask the following questions:

1. Does there seem to be anything wrong in the rationale I used to handle the
32 bit xfers?

2. Because the code works sometimes, and not others, it seems like there may
be some special case I am overlooking.  This suspicion is reinforced by the
fact that when I restrict the read/write multiple to be no greater than 32,
the driver seems to work all the time.  Is there anything that is obvious to
you that I might not be taking into account?


ANSWER:
1. Your understanding of ADD_XFER_IOW appears correct.

2. You still have a data integrity problem:

    - Large transfers
    - Intermittent

When the system does boot, see if you can recreate the problem by running
stress tests (copy/comp) or (xcopy/comp).  Your objective should be to
increase the failure rate so you can get an idea of the type of corruption
that is occurring.

It will be difficult to debug a failed data transfer from the failing
application (pmshell) back towards the driver.  It can be done but this is
beyond the level of support we can provide.

You may have an engineering problem in your adapter.  Some PCI chipsets have
bugs where IRQ is presented before read-ahead data is fully transferred to the
host.  When the driver reads status to clear the IRQ this results in
corruption of the data in the read-ahead buffer.

I would suggest you disable prefetch in the chipset and see if this has any
effect.  Also disable multiple mode support /A:0 /U:0 /!SMS and see if the
increased interrupt rate has any effect.




!GENERAL________________________________**********
April 30, 1995
QUESTION:  (Ref: H11)
Q1. Does the shrink-wrapped version of OS/2 support SMP?  If not, how can I
get one and what is the price?

A1. The shrink wrapped version of OS/2 does not support SMP. OS/2 SMP v2.11 is
available as a separate Package. Marketing should help you with the
Availability and Pricing Information.
==============================================================================

Q2. What are the "certified" hardware platforms that support OS/2 SMP?

A2.  ALR - ProVEISA
     AST - Manhattan
     VTech - Platinum
     Wyse Technology - Series 7000i Model 760
     HP NetServer 5/66 LM2
     TriCord - PowerFrame Model 30
     Compaq - Proliant 2000
     Compaq - Proliant 4000
==============================================================================

Q3. Same question for LAN Server 3.0 and 4.0.  Do they have a special SMP
version?

A3. Two CSDs are available to upgrade LAN Server 3.01. (Or you can use the
SMP CD-ROM). Lan Server 4.0 is compatible with SMP and requires no changes.
==============================================================================

Q4.  Does OS/2 SMP support all existing physical device drivers (especially
NDIS network device drivers) as is?  In other words, is SMP transparent to all
my old PDDs? Do I need to make any changes to my PDD to support SMP or to take
advantage of its potential?

A4. If your Device Driver accesses the Hardware directly without any
involvement from the Kernel you might have problems running it on the SMP.  A
typical example would be if your Driver were accessing the Programmable
Interrupt Controller directly.  Any driver which follows the Intel MPS v1.1
Specification would work without modifications on SMP.
==============================================================================

Q5. Where can I find documents and/or sample code if I want to develop
SMP-aware PDD?

A5. The SMP Reference is available on DevCon DDK Version 1. There are no SMP
sample codes available at the moment on DDK.




!MULTIMEDIA_____________________________**********
April 30, 1995
QUESTION:  (Ref: H07)
There seems to be some inconsistency between the format of RGB16 in the
PCVIDEO sample and the IBMVIDT (VIDVCIT.DLL) sample in the DDK.

The RGB16 defined in the pcvideo sample has the following format:

[0-4] R, [5-10]G [11-15]B, which is the way we want it.

However, in the VIDVCIT.DLL source, the conversion fcn RGB16_TO_IRGB24 seems
to take [0-4] as Blue!  In other words, reversing R&B.  This is causing our
bitmap captured via the Video-In app (from the warp bonus pack) to be reversed
in R&B.

Q1. How do we fix this problem?

A1. There are no inconsistencies in the RGB format in PCVIDEO & IBMVIDT.  You
should be able to fix this problem in your driver.
==============================================================================

Q2. When I build the IBMVIDT source, I can't use it with the Video-In app and
our driver.  I can only use the VIDVCI.DLL that comes with the Video Blaster
driver, why is this?

A2. Please verify that the VSDDRIVER name in the MMPM2.INI and the DLL that
is generated from the source on the DDK do match.  The DDK generates
VIDVCIT.DLL.
==============================================================================

Q3. Currently, our card supports RGB565 as BGR565 (ie:  [bits 0-4] is R).  In
RGBCONV.ASM, around line 607, (fcn is RGB16_to_IRGB24, the routine clearly
expects data in the format RGB565 (ie:  bits 0-4 is B).

The PCVIDEO sample clearly had the VIDVCI.INC file that states in line 145:
DI_IMAGE_RGB_565 EQU 1 ;;; bits 0-4=Red.

We can easily do the conversion in PCV_ReadVideoRect, but note that this
routine has to be done quickly.  Any extra overhead introduced here translates
to lower frame rate and dropouts.

Should we replace the REP MOVS dword ptr .....  with LODSD, convert, STOSD?

A3. Yes
==============================================================================

Q4. Is there another flag we can do to indicate to the VSD that we are
BGR565?

I am also having trouble using VIDVCIT.DLL in place of VIDVCI.DLL, the
Video-In app refuses to MOnitor Video if I use it.  The return code is some
sort of open failure which does not occur with the VIDVCI.DLL.

A4. No flag for BGR565.  This would require changes in the CODECs that
COmpressors and DECcompressors the images.  As for the VIDVCIT, I am not sure
what problem you are seeing.  At what point is it failing?  You may need to
trace thru the OPEN code.  More than likely the Device Driver is not able to
support some flag or operation, or VIDVCIT is unable to read the pddname.INI
file.
==============================================================================

Q5. I replaced the VSDDRIVER= line in mmpm2.ini, is this the right place to
do it?

A5. Yes
==============================================================================

Q6. Also, we can capture video now, but have two problems with it :

     1.  R&B are reversed
     2.  The default video capture size is 640x482, how can I change
         this to a default of 320x240?

A6. The default size is set in two places.

      1) Once the Video IN recorder is opened and set to a size it
          will remember it until you change it... or erase the
          c:\mmos2\swvr.ini file in which case it will recalculate
          the default size.

      2) Your Device driver passes back fields called D_X_WIDTH and
          D_Y_HEIGHT on the DEVINFO call. These field are the device
          default Destination size.
==============================================================================

Q7. Where are all the defaults stored?  Are they in the VIDVBC1.INI file?  If
so, what are the flags we should worry about?

A7. The fields in the pddname.INI file are completely up to your Device
Driver.  The PCVIDEO device driver does not use any filed in the pddname.ini
file to set destination size.  It is hard coded to 160x120 but it could be
saved in the VIDVBC1.INI file.  From the Video IN recorded application you can
set the default record size for real time record and frame step record.  To do
this select OPTIONS then RECORD SETUP and the REAL TIME or FRAME STEP and then
from the record setup note book that appears select the SIZE tab and then
adjust the OUTPUT VIDEO SIZE.  This size will be remembered by the Video IN
recorder until you change it or the SWVR.INI file (INI file for the Video IN
recorder Application).




!OTHER__________________________________**********
April 30, 1995
QUESTION: (Ref. H04)
Q1.  Are there any New DHCALLS.LIB is available for OS/2 SMP V2.11?.  I am
intrested in knowing any new DevHlp_ProcBlock and DevHlp_ProcRun routines
which are supported in SMP.

A1.  DHCALLS.LIB for SMP is not available.You could use the Assembly Code as
documented in the SMP Reference or could extend the existing DHCALLS.LIB.  The
source for OS/2 DHCALLS.LIB is available on the DDK.  2.There are no new
DevHlps for Block & Run.The existing ones for OS/2 are supported on SMP and
should be sufficient.
==============================================================================

Q2.  The SMP.INF file has some information within the section Avoiding Device
Driver Dead Locks and Blocking with SpinLocks Locked.  It specifically states:
"...DevHlp_Block has been modified to release All SpinLocks that are owned on
the current processor.  The device driver should call the DevHlp_ProcBlock
with spinlocks locked."  I'd like to know, Does the current DevHlp_procblock
routine support the above functionality?.

A2.  The DevHlp_ProcBlock for the uni-processor OS/2 has the same
functionality as the SMP DevHlp_Block although the details through which these
are accomplished are different.  The SMP Block releases all SpinLocks that are
owned by the current processor.  ProcBlock re-enables the interrupts and would
run on OS/2 SMP without any modifications to your source (provided the rest of
the code is MP-Safe).
==============================================================================

Q3.  I am using DevHelp_ProcBlock routine in my driver for the IOCTL Path.
Assume that Locks have been created during Initialization of the driver, and
all other variables used are Ok.  Also the DevHlp_ calls for SpinLocks work.

        ....
        .....
        pIOCTL->result = HBAIO_NOTDONE; // set to other than this in ISR.
        // Code for Sending the command goes here.

        SendCommand

#ifdef SMPV211
        DevHlp_AcquireSpinLock(npACB->ISRLockHandle);
#else
        DISABLE;
#endif
        // pIOCTL->result is set to HBAIO_NOTDONE before sending the command.
        while ( pIOCTL->result == HBAIO_NOTDONE ){
                DevHelp_ProcBlock((ULONG)physaddr,-1L,1);
#ifdef SMPV211
        DevHlp_AcquireSpinLock(npACB->ISRLockHandle);
#else
        DISABLE; // CLI
#endif
        }

#ifdef SMPV211
        DevHlp_ReleaseSpinLock(npACB->ISRLockHandle);
#else
        ENABLE;
#endif

I had put an "int 3" statement after ProcBlock call.  When it enters Kernel
Debugger, I have used .DL command in KDB to check for the SpinLocks active on
that processor.

According to the documentation ProcBlock will unlock all the spinlocks on the
current processor.  But I found that my SpinLock (ISRLockHandle) was still
active.  When it Acquires the spinlock in the while loop again, I found that
nested count increased to 2,3 etc and finally debugger displayed a message
"...  Lock:  Invalid Lock nesting"

Can you explain why it happened or is there any chance that above situation
(Not unlocking Spinlocks) can occur?.

A3.  During blocking, the OS will record and release the spinlocks held by a
given thread.  However, and this is where the confusion is, when the thread is
redispatched, the OS used the recorded information to re-acquires the
spinlocks the thread owned prior to being blocked.  In the code fragment
included in your note, it was obvious that the DD was ALSO re-acquiring said
spinlock in addition to the OS doing so.  The result is that each pass through
the WHILE loop causes an increment of the spinlock's nesting level until its
becomes nested too many times.  Eliminate the re-acquiring of the spinlock in
the WHILE loop, and everything will work correctly.




!PRINT__________________________________**********
April 20, 1995
QUESTION:  (Ref: H23)
I am just starting to use the DDK to develop a printer driver for OS/2 Warp.
I ran the MINIDRIVER2 driver just to make sure my development environment was
ok and I created a MINIDRIVER2 driver just fine.

I tried the same thing with the PLOT32 printer driver but the results were not
the same.  I received the following error:

    The name specified is not recognized as an ... command ...
    Nmake : fatal error 1077: c:\os2\cmd.exe : return code '17'
    Stop

I cannot seem to build the PLOT32 driver.

Q1. Is my development environment set properly?  Could you please provide a
response as to what the problem may be?  This error occurred while trying to
compile the file attribs.c (the first file compiled in the makefile).

A1. Please see the build instructions for the 32-bit plotter in the Using Your
DDK Components & Build Requirements.  We've noticed that step #3 for the
PLOT32 was not required to build the MINIDRIVER2, so maybe this is your
problem.  Also, I assume you are using the correct compiler(s).
==============================================================================

Q2. Also, where is the include file 'pmwinp.h' located?  This file is included
in c:\ddkx86\src\prntdd\ibmh\pmp.h.  Apparently this file is needed but I have
no idea where to get this file.  I checked the DDK for this file but could not
find it.

A2. This file is no longer required.  The following information is taken from
the README section of USING YOUR DDK, on the Devcon DDK, under the DEVICE
DRIVERS heading:

Any device drivers that previously referenced the files PMWINP.H or PMWINP.INC
have been changed to reference the files PMWINX.H and PMWINX.INC.  If you are
migrating to the current DDK, change any drivers on previous DDKs that
referenced the files PMWINP.* to refer to the new PMWINX.* files.




!OTHER__________________________________**********
April 20, 1995
QUESTION: (Ref: H19)
I have a NDIS PCMCIA device driver that was compiled using Microsoft Assembler
6.11.  Do I need to downlevel to Microsoft Assembler 6.0?.

If so I'd be curious why I saw a message in the February notes that said 6.11
didn't support OS/2.  Specifically, what makes 6.11 incompatable with OS/2 vs
6.0.

Anyway, I'm re-assembling the driver using 6.0.  Noticed some interesting
things in 6.0 that were fine in 6.11.

I noticed that the following statement worked fine in 6.11 but not in 6.00

    mov al, es:[di]

I had to change it to:

     mov al, byte ptr es:[di]

 in order to assemble under 6.0.


ANSWER:
The DDK specifies that MASM 6.0 is needed to compile drivers because drivers
on the DDK were compiled using MASM 6.0 and not MASM 6.11.




!VIDEO__________________________________**********
April 20, 1995
QUESTION:  (Ref: H05)
Q1. We are writing a driver for a combination video capture/tv tuner board.
Do you have sample code for us to use to write an application for a tuner?  I
assume this application talks to VIDVCIT.DLL at some level.

A1. At the moment we do not have any sample application codes for the Tuner.
==============================================================================

Q2. Also, the VIDVCIT.DLL build from IBMVIDT on the DDK cdrom does not work
with the pcvideo source code.  Is this normal?

A2. Please verify that the VSDDRIVER Name in the MMPM2.INI and the DLL that is
generated from the source on the DDK do match.  The DDK generates VIDVCIT.DLL.
==============================================================================

Q3. Lastly, if you can give me a template for the missing tuner.asm file for
the pcvideo sample, it will be very useful.

A3. The source should be available in the Chips & Technologies PC Video
Software Developers Kit.




!MULTIMEDIA_____________________________**********
April 20, 1995
QUESTION: (Ref: GY7)
I record PCM files, LINEAR 44.1kHz stereo, on my 486DX2-66.  If I record
silence, I get many zeros at the beginning of the file.  The file has no
header and begins with many zeros (50,000 zeros).  When the PM application
calls mmioOpen() to open this file with many zeros at the beginning, it takes
a very long time to open the file!  For example, if there are 10,000 zeros, it
takes 9 seconds to open the file; and if there are 20,000 zeros, it takes 18
seconds to open the file but if there are 20,000 bytes of any other value, it
takes only 1/10 of a second to open the file.

This is a very critical problem because 5 seconds of silence at the beginning
of a PCM stereo 44.1 kHz file = 882,000 bytes of zero; and with 882,000 bytes
of zero, mmioOpen() takes 13 minutes to open the file.  So, the customer
thinks that the machine has crashed.

Q1. Do you have an explanation?

A1. We have no explanation, but there is a workaround to try.  Try using the
following code:

         memset( &mmioinfo, '\0', sizeof( MMIOINFO ));
         mmioinfo.fccIOProc = FOURCC_DOS;

and then do the mmioOpen call.

This will cause the open not to do a mmioIdentify.
==============================================================================

Q2. The flag "MMIO_NOIDENTIFY" sometimes solves the problem, what does this
flag mean?

A2. Normally mmioOpen() calls mmioIdentifyFile() to determine the correct
IOProc to use for the file.  Specifying MMIO_NOIDENTIFY instructs mmioOpen()
not to use mmioIdentifyFile() but to use other means to determine the proper
IOProc.  If no other means are available or they prove unhelpful, the default
DOS IOProc is used.




!STORAGE________________________________**********
April 20, 1995
QUESTION: (Ref: GY6)
I am interested is OS/2's behavior under  the following conditions.

I am currently writing a SCSI device driver (not for disks) for a new PCI card
that will be replacing our old MCA card.  During the development, I noticed
some things about the old driver which has been in the field for about 2 1/2
years.  This is what the old driver does.

1) An IOCTL call that passes an application address (16 bit app) to the device
driver.  The device driver verifies this address and stores it.  The address
points to a two byte location within the application.

2) On a read/write call, the device driver passes miscellaneous information
using this address at task time.  The device driver does not revalidate/lock
this area but interrupts are off.  IF THE ADDRESS IS VALID BUT SWAPPED TO
DISK, WILL OS/2 SWAP IT BACK IN, EVEN WITH INTERRUPTS OFF OR WILL THERE BE A
HANG IN THE DEVICE DRIVER?


ANSWER:
If the address is valid but swapped to disk, OS/2 needs to access the disk to
bring the page into memory, since interrupts are disabled this will not be
possible so the DD might HANG.

OS/2 specifies that a maximum interrupt disable time of 400 micro- seconds is
acceptable.  This ensures that the system can respond rapidly to the needs of
time critical threads and also be flexible enough to allow a user to switch
between programs quickly.

In case you are using the Interrupt disable in the ISR, you could use Context
Hooks to push some of the processing to Task time.

Also, using DosAllocMem with the OBJ_TILE bit might help.  This will ensure
that you are in the Compatibility Region-first 512MB of Virtual Address Space.




!OTHER__________________________________**********
April 20, 1995
QUESTION: (Ref: GY0)
I have come up with a generic move function that would support 8, 16, and
32-bit moves using either virtual (16:16) or linear (16:32) addressing.  I've
coded it, debugged it, and started using it, but I've run into another bump.

In the first cut of the function, I hard coded use of the 53h descriptor which
is the descriptor applications use for DS.  I was leary of this because I'm
not sure that furture versions of OS/2 will set this descriptor up the same
way, so I planned to have applications pass DS to the driver via an IOCTL
call.  This idea would have allowed my driver to adapt to any changes in the
application data descriptor.  However, my driver also has to support reads and
writes to dual ported memory.

A DPM region can be greater than 64K in size and since it needs to be
accessible to other VMEbus masters over the VMEbus it must be contiguous and
never swapped.  In order to allocate these DPM memory regions I used VMAlloc,
but since the memory had to be able to be over 64K, contiguous, and fixed, I
could not allocate it in process space.  This leads me to the bump - globally
allocated memory by design resides outside of the range of addresses
accessible by the application data descriptor.

I have been able to temporarily get around this by dumping the GDT and finding
another descriptor (which is still hard coded into the move function).  Right
now I'm using descriptor 168h which allows access to the entire 32-bit (4GB)
address space.  The big problem is that I can not think of a way to
programatically get at this descriptor (in the same way an application could
IOCTL my driver with the application data descriptor).

Will the 168h descriptor be set up the same way in future versions of OS/2?
If not, is there a way to determine the 4GB descritor programatically?


ANSWER:
Do the following:
1) allocgdtselector
2) manually initialize allocated descriptors to 4 gigabyte address space
3) use new descriptor to access PDD buffer




!MULTIMEDIA !OTHER______________________**********
April 20, 1995
QUESTION: (Ref: GW6)
Q1. Is it possible to implement an audio device driver as a 32-Bit DLL instead
of a physical Device Driver?

A1. No, because the audio PDD needs to service interrupts from the Hardware
adapter.  An ISR can only execute at Ring 0 therefore you need to have an
audio PDD.
==============================================================================

Q2. Is it possible to set up a call-gate so that a Ring 0 Physical Device
Driver can call into a 32-Bit DLL and vice versa?

A2. No.  Call gates are used to transfer control from a lower privileged ring
such as Ring 3 to a higher privileged ring such as Ring 0.

You could use the DevIOCtl calls to call the PDD from a Ring 3 application
/DLL:

Normally a Ring 0 application cannot upcall or call a Ring 3 application
because this would violate the protection mechanism of the 80386 CPU.
Indirectly you could achieve the same effect by having the Ring 3 application
spawn a Ring 3 thread, which creates an Event Semaphore, passes the handle to
the DD via IOCtl call and then blocks on the semaphore.  Once the thread
awakens after unblocking from the semaphore the thread could do a call to the
required application code (upcall routine) and then go back to wait on the
semaphore after returning from the upcall routine.  The DD can trigger the
semaphore at task time using the PostEventSemaphore devhelp whenever it wants
to initiate an upcall sequence.  In case the upcall has to be done during an
interrupt sequence (interrupt time), the DD can use a context hook (refer to
AllocateCtxHook, ArmContextHook devhelps in PDD reference) routine to do a
PostEventSemaphore for initiating an upcall sequence.
==============================================================================


Q3. I am trying to give a 32-Bit DLL access to some memory in the audio
Physical Device Driver.  Here is a diagram of the architecture and a brief
overview of how it works a list of what I have tried so far.

                                           Resource Manager PDD/32-Bit DLL
      -----------                  ---------------         ------------------
      | AudioDD |                  |  HW General |<------->|   HW General   |
      |   PDD   |                  | Service PDD |         | Service 32-Bit |
      -----------                  ---------------         |     DLL        |
          |                               ^                ------------------
          |                               |                        ^
          |                               |                        |
          +------------+      +-----------+                        |
                       |      |                                    |
                       |      |                                    |
                       V      V                                    |
                    ----------------                               |
                    |  Video/Audio |<------------------------------+
                    |   Adapter    |
                    ----------------


In our architecture, there is a combination PDD/32-Bit DLL which manage the
Hardware Resources.  The PDD is mainly used for receiving the hardware
interrupts.  It will actually process the interrupts that need to be handled
at interrupt time during VBLANK such as HW Cursor and HW Palette.  For all
other HW notifications, a system critical thread in the 32-Bit DLL is woken up
which will perform all other Resource Management operations.

Our hardware is programmed in an object oriented manner.  What this means is
that a client of the hardware programs the hardware by creating objects and
invoking methods on the objects created.  Some of these method invocations
will be handled directly by the hardware while others will cause an interrupt
meaning it must be handled by the Resource Manager components.

One of these methods is the naming of objects created by the hardware client.
When a client creates certain objects, it must provide a unique name for these
objects.  These names are actually character strings.  It does so by invoking
a method during object creation which provides a pointer to the string
containing the name for the new object.  In other words, it writes the pointer
to a designated memory mapped hardware register.

When the 32-Bit Resource Manager DLL tries to service this particular method,
it gets the pointer to the string from the hardware register and attempts to
set up access to the memory by calling the Resource Manager PDD to perform the
necessary tasks so it can properly access the memory (in this case to be able
to read the data from the memory location).  In the case of a 16:16 address
from the PDD, it needs to be converted to a linear address in the Resource
Manager's space.

This is where I'm running into problems.  I have tried various methods to get
accessibility and none have worked.  I have tried the following:

a) Using the actual pointer to the string in the AudioDD's data segment.

b) Using DevHelp_AllocPhys/DevHelp_PhysToGDTSelector and copying the data to
the allocated memory and then using the GDT Selector/Offset pair.

c) Using DevHelp_AllocPhys/DevHelp_VMAlloc with the allocation flags set to
0x410 (VMDHA_PHYS | VMDHA_SELMAP) and using passing the flat linear address
obtained as well as using FlatToSel to get a Selector/Offset pair and passing
that pointer.

d) Using DevHelp_VMAlloc/DevHelp_LinToGDTSelector and then passing the GDT
Selector/Offset pair.

None of these methods has allowed the 32-Bit DLL to access the memory.  I am
out of ideas on what to try in order to get the address mapping such that I
can access it.  Also, please note that performing a similar operation from the
display driver which is a 32-Bit DLL has worked without any problems.  This
(as well as other reasons) is why a 32-Bit DLL Audio Driver in our case would
be a better solution...if there is a way that the Stream Handler can
communicate with it that is.

A3. In the PDD use AllocPhys and PhysToUVirt devhelps with request_type =
SELTYPE_R3DATA or use AllocPhys and PhysToGDTSel with access parameter =
GDTSEL_R3DATA if the memory requirement is less than or equal to 64K

Ref : GETINSTANCEGDT routine in DDKX86\SRC\PMVIDEO\XGASYS20\XGARING0.ASM

If you require more then 64K of memory:

     use VMAlloc to allocate global memory and then use VMGlobalToProcess
     devhelps to get linear address for your DLL
                       or
     use VMAlloc to allocate memory in the process context. Use
     VMDHA_PROCESS  VMDHA_FIXED  VMDHA_CONTIG  VMDHA_SELMAP for the flag
     parameter.

Ensure that you have a linear address to the memory mapped hardware register
address via the PDD.  Your PDD needs to convert the memory mapped hardware
register address to a virtual/linear address accessible in the R3 context and
pass it to your 32-bit DLL via an DevIOCtl call.

Refer to
         ddkx86\src\pmvideo\32bit\eddefpdb.c,
         ddkx86\src\pmvideo\xgasys20\xgaring0.asm

for details regarding IOCtl interface from 32-bit XGA display driver DLL to
xgasys20 PDD & for converting memory mapped H/W register to virtual/linear
address to be used by the XGA display driver DLL.




!OTHER__________________________________**********
April 20, 1995
QUESTION: (Ref: GW3)
I am working on a DLL to hook into the GRE entry table via.  OS2_PM_DRV_ENABLE
subjunction 0x0C.  I am able to compile a DLL and register it to hook the
functions.  The problem is that I need to be able to perform IPC with a Ring 3
application.  So far I have attempted to setup a Queue in the ring 3 app, when
the DLL opens the queue to post a message the first time I get an error number
328 (ERROR_SYS_INTERNAL), but after that it is able to open the queue.  I have
tried to use Semaphores which seem to work most of the time, but at times the
posted count on the event semaphore changes without any interference from me.
Using named pipes when I attempt to do a DosOpen, I get a return code of 3
(path not found).

For the named pipes I found a call PrtOpen that looks like it is what I should
be using (the online docs in Presentation Driver Ref say that this can be used
to open named pipes) but the system locks when I make the call.

Overall I am getting the impression that these Dos calls are not valid from my
hooked function calls.

From my debug output, it would appear that my hooked function calls are being
called by multiple threads.  That is it appears that they are not sequential,
this makes a difference on how I handle the IPC from my ring 3 app.

If you have any suggestions as to how I can get my information into and out of
these function calls to my ring 3 app I would greatly appreciate it.


ANSWER:
Check if your DLL is Ring 2 conforming.  By default the graphic engine calls
all the functions in the dispatch table as Ring 2 conforming.

Since you are hooking the graphic engine and display driver functions via the
dispatch table, your filter routines need to support multithreaded operation.

If your DLL is Ring 2 conforming you could issue all the Dos calls from your
hooked function.

Make sure you always pass on control to the system.  Refer to the sample code
in DevCon 6 (in the "Source Code from the Developer Connection News"
Category).  In the sample code we call back the CharStringPos() address that
was stored earlier so that the rest of the system could proceed normally, if
required.

You could also refer to the Developer Connection News Vol.6 which has an
Article on Monitoring Display Driver Interface Calls.  The relevant source
code is also available on DevCon 6.




!OTHER__________________________________**********
April 20, 1995
QUESTION: (Ref: GU9)
I am trying to modify the SERIAL.PDR DLL (serial port driver) in the DDK
source (\DDKX86\SRC\SERIAL\SERIAL.C) so that it supports more than the COM1-4
ports.  This doesn't seem very hard to do.  I have successfully built the DLL.
How do I install it?  I have copied SERIAL.PDR to \OS2\DLL and rebooted but
judging from what I see when looking at Output settings for a printer object
nothing seems to be changed.  The documentation for this type of driver seems
to be virtually non-existent.  Is there anything more than what I see in the
Presentation Driver Reference (1 page)?


ANSWER:
Use PrfWriteProfileString and update relevant App.Name,Key Name & Values in
OS2SYS.INI.

Update the following Application Names -
PM_SPOOLER_PORT,
PM_<Port Name>
PM_PORT_DRIVER
An example would be ,

Application Name      Key Name              Value

PM_PORT_DRIVER,        SERIAL,     C:\OS2\DLL\SERIAL.PDR

PM_COM5,           DESCRIPTION,     Serial Port COM5;
PM_COM5,        INITIALIZATION,         9600;0;W;8;1;
PM_COM5,           TERMINATION,                     ;
PM_COM5,            PORTDRIVER,               SERIAL;
PM_COM5,               TIMEOUT,                   45;

PM_SPOOLER_PORT,COM5,                   9600;0;W;8;1;




!BASE___________________________________**********
April 20, 1995
QUESTIONS to follow (REF: GS6)
I am trying to avoid writing a VDD.  We manufacture airfield lighting control
systems.  The signal monitoring system, which I will refer to as the "scanning
monitor", is the portion of the software that is having the problems.  We are
currently porting the entire software solution from MS-DOS to OS/2 v3.x.  The
port will be a multi-staged release of the system that has portions of the
code running in native OS/2 processes and portions running in a VDM.  The
scanning monitor will be running in a VDM.  This process interacts with a
DataTranslation A/D card to sample signals from the power supplies in order to
determine how well the system is running.  The problem is such that after a
few DMA transfers have been requested, the programs stack gets corrupted.  The
assumptions are as follows:

1. Direct access of the A/D card appears to work.  Since no other process in
the system needs access to the A/D card a device driver should not be needed.

2. A virtual address is being loaded into the DMA chip directly from the DOS
program via outport() commands to the appropriate I/O addresses.


The questions are as follows:

Q1. If assumption #1 or #2 is incorrect please advise.

A1. Assumption #1 is OK. Assumption #2 in not correct. Instead of a virtual
address try a linear address if you are using VDMA.
==============================================================================

Q2. Given assumption #2, does VDMA.SYS automatically map the address being
loaded into the DMA chip into the appropriate physical address?

A2. VDMA.SYS converts DOS sessions linear addresses to physical addresses and
handles all the data movement required.
==============================================================================

Q3. Should we be using a different method to load the DMA chip, i.e. MS-DOS
INT routines ?

A3. You could use INT 4Bh, function 81h, VDMA services. Refer to the Virtual
Device Driver Reference, Base VDDs chapter, VDMA Device Driver section.
==============================================================================

Q4. If VDMA.SYS re-maps the address, how can I verify that it is indeed
working correctly?

A4. Use the Kernel Debugger
==============================================================================

Q5. Given that everything is working correctly, how do you suggest that I go
about finding the source of my problem?

A5. Confirm that there is no interrupt conflict in the system between A/D card
and other cards.

Disable interrupts during DMA setup and while loading DMA registers.  Refer to
Appendix C, Sample DMA sources in Mastrianni's book for steps and as a sample
(It is a PDD, but steps will be same)

If your design does not require you to write an ISR for handling the A/D card
and there is NO chance of simultaneous access from different OS/2 applications
to the A/D card then you do NOT need a PDD.  The required I/O for DMA and
other related programming can be done by a portion of your code which has IOPL
(I/O privilege).
==============================================================================

Q6. When the entire system has been ported to OS/2 will I need to have a PDD
for the A/D card, or can I access it directly as long as only one process in
the system has access to it?  Keep in mind that we are using DMA transfers
with the A/D card.

A6. It would always be preferable to have a PDD.  This ensures greater
portability and compatibility.  There would be no resource conflicts if you
would use with the Resource Manager in Warp.  However, if you are not
concerned about resource conflicts and a multitasking scenario, the PDD is not
really essential.




!OTHER__________________________________**********
April 20, 1995
QUESTION: (Ref: GS2)
In attempting to build the code in the \DDKx86\SRC\VGA32\SVGA256 subdirectory,
using MASM 6.0B, I have discovered that the source, as supplied by IBM, does
not assemble.

Three files (CURSOR2.ASM, SCANLINE.ASM, and ENUMBANK.ASM) produce fatal
errors.

Likewise, in IBMVGA32, the file THUNK.ASM causes two fatal errors:  both
because parameters declared for the two functions in PROTOS.INC are missing
from the functions in THUNK.ASM.

It looks to me like either:  (1) MASM 6.0B is _not_ the correct version of the
assembler (is IBM's production version the buggy 6.0A, perhaps?), or (2) the
SVGA code in the DDK is NOT production code.

1) Am I using the wrong assembler or is there a problem with the source?

In the file CURSOR2.ASM, MASM 6.0B produces errors such as the following:

CURSOR2.ASM(963):  error A2107:  cannot have implicit far jump or call to near
label


ANSWER:
The Build Requirement for the 32 bit VGA Display Driver is MASM Version 6.00
and not MASM 6.0B.  The code in the DDK is the Production Code and as stated
in DDK documentation requires Microsoft Macro Assembler Version 6.00

A warning will be placed in future DDK releases warning of incompatibilities
with MASM 6.0B.




!OTHER__________________________________**********
April 20, 1995
QUESTION: (Ref: GS0)
I finally received the Microsoft Window 3.1 DDK Modified Code for WIN-OS/2
Seamless VGA, and I tried to use DebugOut defined in

          WINOS231\DRIVERS\DISPLAY\4PLANE\DEBUG.ASM

with my own seamless driver so that I can see debugging information from my
kernel debugger terminal.  I have no luck with it at all.  When I trace into
the module, I can see that it is doing everythign correctly until it gets to

terminate_and_send:

;       /* NULL terminate the string and make the call to VXMS */
;       /* ES:DI = array;
;       /* DS:SI = "VXMS";
;       /* AH    = 2;

        mov     BYTE PTR es:[di], 0

        mov     di, OFFSET array
        mov     si, OFFSET vxms_id
        mov     ah, 2
        int     66h


and nothing hapens.

Does this only work with the VGA seamless driver, or can I use DebugOut with
my own seamless driver?


ANSWER:
In DEBUG.ASM, instead of the INT 66h Section of the code, use the Windows API
- OutputDebugString which is a Windows 3.1 API.  Refer to the documentation on
Windows Kernel Functions.

Try using the library - swinlibc.lib

Here is a sample code -

externFP    OutputDebugString

public DebugOut
DebugOut PROC FAR

        :
        :
        :
        :
;<001> Start
        ; NULL terminate the string and call OutputDebugString.
        mov     BYTE PTR es:[di], 0
        mov     di, OFFSET array
        push    es
        push    di
        call    OutputDebugString
;<001> End.


if 0    ;<001>
;       /* NULL terminate the string and make the call to VXMS */
;       /* ES:DI = array;
;       /* DS:SI = "VXMS";
;       /* AH    = 2;

        mov     BYTE PTR es:[di], 0

        mov     di, OFFSET array
        mov     si, OFFSET vxms_id
        mov     ah, 2
        int     66h
endif   ;<001> if 0
        :
        :
        :
DebugOut ENDP




!OTHER__________________________________**********
April 20, 1995
QUESTION: (Ref: GQ4)
Can my device driver use the OS/2 TRACE facility?  That is, can I write trace
records from my device driver.  I can find no reference of how to do this,
though I noticed that the DevHlp routines can be traced.  This implies that I
can.  Is there any doc on how to do this?


ANSWER:
You can find samples of using TRACE in the DDK.  Look at the following code:
DDKX86\SRC\DEV\DASD\OS2DASD\DMTRACE.C




!PRINT !OTHER___________________________**********
April 20, 1995
QUESTION: (Ref: GL8)
I've suddenly acquired a problem while compiling using EA.exe.  It crashes
with an access violation.

I'm currently building a Postscript Level 2 printer driver using OS/2 WARP,
the Developers' connection kit, and the Toolkit for OS/2 WARP.  The makefile
uses EA.exe (in \ddkx86\tools directory) to add extended attributes to my
driver.

The driver is still built but I can't load it.  The error that I get is access
violation at 1:00002248 in EA.EXE.  EA is called out several times from the
makefile.  The 2 instances where it crashes are on the lines that add
"RequiredDriverFiles" and "OptionalDriverFiles" extended attributes to my
driver.

The following is a dump of the registers when EA.EXE crashes:

A program generated an access violation at 00012248.
EA.EXE 0001:00002248
P1=00000000 P2=ffffffff P3=XXXXXXXX P4=XXXXXXXX
EAX=00000000 EBX=0000076c ECX=00007534 EDX=00000000
ESI=00005320 EDI=00005320
DS=0017 DSACC=00f3 DSLIM=0000531f
ES=0017 ESACC=00f3 ESLIM=0000531f
FS=150b FSACC=00f3 DSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=000f:00002248  CSACC=00fb  CSLIM=0000299b
SS:ESP=0017:000032b4  SSACC=00f3  SSLIM=0000531f
EBP=000032ba  FLG=00012202


ANSWER:
We have observed this problem too and a defect has been opened.  The driver
does compile, but you may need to manually add the extended attributes.




!MULTIMEDIA_____________________________**********
April 11, 1995
QUESTION: (Ref: GZ5)
I have been trying to develope a MIDI out driver for our sound card by using
the examples that come with DDK v6 (PASTK), but have been having difficulty.

All of the communications is complete, the driver is up and running and the
system thinks it is a midi device.  The MIDI stream of data that I receive has
the embedded time sysex messages in it.

What I would like to know is if there is a generic MIDI ONLY device driver
(source code) that I can use as referance to parse this data?

The PAS driver that supports MIDI play is helpful but it is difficult to
follow because of the mixture of digital audio and MIDI commands.  Really all
I want is a driver that just does MIDI play.  Also the documentation that
comes with the DDK is very poor in explaining the midi implementation.


ANSWER:
At this time, there is no sample source code available.




!OTHER__________________________________**********
April 11, 1995
QUESTION: (Ref: GX9)
I am interested in finding out if there are any books written about .ADD
development for OS/2 2.1 or 3.0.  I tried to contact John Soyring on
Compuserve to find out if his writings were available.  Any help would greatly
be appreciated.


ANSWER:
I'm sorry but there are no books available on OS/2 ADD development at this
time.  The only ADD References that we are aware of are those on the DDK.  You
might also try the Adaptec BBS for Programming Specifications.




!STORAGE________________________________**********
April 11, 1995
QUESTION: (Ref: GX5)
How feasible is it to install a file managment system in OS/2?

This file management system would be like DF/HSM on MVS.  MVS allows open
exits.  That is, whenever a file is opened, a user written piece of code (that
is linked into the operating system) can get control to perform certain
actions.

When a DosOpen is issued under OS/2, we want to be table retrieve the file
from a backup tape or disk, and restore the file on to the hard drive and then
let the normal open process regain control.

As far as I know, there are no open exits in OS/2.  The only thing that may be
possible it to use an IFS.

My question is:

1. If we write an IFS, can it manage all the hard drive letters
(i.e. C:to Z:)

2. Can an IFS pass control to another IFS (like IBM's HPFS)?

I am guessing that this is roughly what Stac corporation does for their
STACKER software for OS/2 (I have never seen a copy in action).  I believe
that their product does not work for HPFS partitions.


ANSWER:
There is no mechanism to 'over-ride/intercept' file I/O operations to existing
file systems like HPFS/FAT.  If one were to write an IFS to do this, it could
only manage those files that are on its drives.  You COULD redirect the open
back to the real drive (which some others have done, like TVFS on the Devcon
CD) but this would be a different drive letter (E:  for your IFS redirecting
back to the real C:  drive).




!VIDEO__________________________________**********
April 11, 1995
QUESTION: (Ref. GU3)
We are using the PM_ED_HOOKS to intercept calls from the graphics engine to
the PM display driver.

On a complex CharStringPos call (eg. rotated or sheared characters) we want
to force a graphics engine simulation, rather than passing the call to the
display driver (and hoping it calls the simulation).

We attempt to do this by calling the address at offset 0x36 (from the
CharStringPos function number 0x7036) in the table pointed to by
param2->pEngHooks (that is, the 0x37th entry since the table is zero based).

Param2 is the third parameter to OS2_PM_DRV_ENABLE, subfunction 0x0c. It is
a pointer to an INSTALLMON2 structure, ie

    typedef struct _INSTALLMON2
    {
        PDCINT pEngHooks;
        PDCINT pDrvHooks;
    } INSTALLMON2;
    typedef INSTALLMON2 DCPTR PINSTALLMON2;

The result is a trap shortly after the call to param2->pEngHooks[0x36]. This
occurs on a repne scasb instruction where the es:edi destination is invalid.
The problem is the edi register. This has been loaded with the first
parameter to the function, ie the hdc. As this is not a pointer, a trap
results.

The parameters passed to the param2->pEngHooks function are identical to
those received in our hook. They are pushed in the same order. In other
words the stack frame for the param2->pEngHooks call is identical to that
for our CharStringPos hook function.

We have tried setting a breakpoint on the param2->pEngHooks function address
but it is never hit, except when called from our CharStringPos hook.

Are we doing something wrong?


ANSWER:
pEngHooks is a pointer to a different table than the pDrvHooks.  So the
pEngHooks address at offset CharStringPos for the pDrvHooks table contains
either a different address or none at all.

Since the current display driver overlays the drv dispatch table first, and
since Charstringpos is an old model mandatory call there is no way that you
can get the address to the engines default simulation routine through the
PM_ED_HOOKs interface.

Unfortunately this is the first request for querying the engines default
simulation routines, so we do not have a process in place to do that.  The
only way I can think of currently to get that is to write a stub presentation
driver, perform a DevOpenDC on it, and when the stub driver gets its
ENABLE_PDEV call record the address you need at that time.




!OTHER__________________________________**********
April 11, 1995
QUESTION: (Ref: GS9)
I have a few questions pertaining to device driver development.  We will be
developing drivers for OS/2 2.1 and 3.0 for our high-speed WAN cards.

1) What compiler should we use for driver development?
2) Will os/2 2.1 drivers work on warp?


ANSWER:
1. OS/2 device drivers on the IBM DDK were written in MASM 6.0 and MSC 6.0.
Another option that you may want to consider is the Watcom compiler.  Although
we have not written any drivers using this compiler, we have been told by
IHV's that they have been using the watcom compiler.

2. OS/2 2.1 drivers will work under WARP.  You may want to download the file
RMBASE.ZIP from the DUDE which describes the Resource Manager feature in WARP.




!VIDEO__________________________________**********
April 11, 1995
QUESTION:(Ref: GI5)
We want to support the new videopmi interface with our graphics drivers.  So
my questions are:

1. What files do I need?  As I know, these are BVHPMI.DLL, VIDEOCFG.DLL and
VPMI.SYS.  What about the PM driver?

2. Where do I get these files?  I heard, they are available at S3 on
CompuServe, but I don't know the name of the S3 forum.  Perhaps, you could
send me an installable set of drivers via E-Mail (rheidelb@msmail.miro.de) or
disk.

3. How is drawing implemented?  Is it done with linear addressing?  And if so,
what PM driver must I use?


ANSWER:
In order to support the videopmi interface and the configuration that comes
along with it, a PMI file has to be created which passes the criteria
described in the VIDEO PMI document in the DDK.  The PMI file needs to have a
hardware section, traplist section, identifyadapter call, modeinfo sections
followed by modesets.  The modeset functions can be implemented in the PMI
file itself or exported to a binary object.

You could refer to the sources in the \ddkx86\src\ibmgpmi\ipmi*.c to see how
we use the imported binary objects.  Depending on in what format is your
current source for the set mode, the quickest method may be to build that into
a DLL and export your setmode entry point to the PMI file (VIDEO PMI document
describes how is this done and IBMGPMI and all of our PMI files document
that).  The PMI file is currently formatted using the SVGA.EXE whose source is
also in the DDK src\svdh\svgautil.  You could write your own svga.exe from
scratch to format the PMI file, or add your adapter support to the existing
svga.exe.  The latter may prove difficult, since the code is very complicated.

Apart from the PMI file, the changes need to be made to the virtual driver
(src\vdev\vvideo\vv*.c).  The best is follow the template used for other
chips, loot at vvs3.c, vvati.c or vvcirrus.c.  The effort involved is just one
source file + entry in the vvpmi.c for the new device.  The svga functionality
is enabled only when a PMI file is found.  No changes to the BVHSVGA need to
be made.  The display drivers in the DDK do not use linear apertures.  We may
have some samples in future DDK.  The S3 source is probably the best starting
point, but since it is all engine acceleration based, a lot of it has to be
customized for the particular chip.

In the base video bundles in the diskette image for the S3 driver is the new
videocfg, videopmi, bvhsvga and other MR1 version binaries which you do not
change.This could be obtained from CompuServe -

S3_864.ZIP is on OS2SUP Library 23, IBM Files [SUPP]

  [76711,175]     Lib:23
  S3_864.ZIP/Bin  Bytes:2345314, Count:  102, 01-Dec-94

        Title:        OS/2 2.1 and higher S3 864 driver
        Keywords:     S3 864 VISION864 86C864 DISPLAY GRAPHICS UPDATE.




!OTHER__________________________________**********
April 07, 1995
QUESTION:  (Ref: GX7)
I'm having some difficulty trying to locate copies of both Microsoft C version
6.0 and MASM version 6.0.  Where should I go to get a copy of these products?


ANSWER:
You may attempt to acquire MASM v6.0B using the following procedure:

Purchase MASM 6.11 from a reseller and call Microsoft with the registration
number to order a downgrade.  As of 08/23/94, approximately 7 to 11 copies of
MASM 6.0B were in inventory at Microsoft.  Also, Microsoft C 6.0 and/or
MASMv6.0 may be available through software resellers.

Please be aware that using MASM v6.0B with the DDK will produce compilation
errors which require some coding changes to reconcile, but it is usable.




!OTHER__________________________________**********
April 07, 1995
QUESTION: (Ref: GX0)
I have installed OS/2 SMP V 2.11 on IBM PC Server with 2 PROCESSORS.  I have
used DDK Version 1.2 CDROM to install Kernel Debugger onto SMP System.  After
the KDB is loaded, it asked to reboot the system.  But , system does not boot
at all.  It does not come to a stage where it displaus OS/2 LOGO.

1) Am I doing something wrong?.  Can you suggest me anything on this?.

2) Is there any new KDB available for OS/2 SMP?.


ANSWER:
There is no SMP KDEBUG on the DDK.  You need to use the KDEBUG from the SMP cd
or DEVCON cd.




!OTHER__________________________________**********
April 07, 1995
QUESTION: (Ref: GW5)
I am having problems compiling ddkx86\src\dev\pcmcia\socket\*.  I have done
ddkx86\setup\copyasm6, after installing MASM 6.11, but no .obj files get
produced and I receive no error messages until the link phase attempts to
reference ssos2drv.obj.


ANSWER:
The Build Requirement for the Socket Services Driver is Microsoft Macro
Assembler Version 6.00.

Go to the DDKX86\MASM60\BINP directory (this is created when you execute
COPYASM6.CMD) and execute "ml" to get the version.  The Assembler is not being
invoked either because of the Environment or an Incorrect Version.  Also,
refer to the Build Instructions in the USEDDK.

MASM 6.11 is not the OS/2 Version.  MASM 6.0 was the last Microsoft Assembler
on OS/2 and you need to have this to run the DDK Code.  The other alternative
would be to try modifying the code for MASM 5.1 which is available on the DDK.




!STORAGE________________________________**********
April 07, 1995
QUESTION:  (Ref: GU5)
What do I need in order to create device drivers for OS/2?  I also want to
develop an IFS for tape drives.  Please let me know what I need and where I
should go to get it.


ANSWER:
The OS/2 Device Driver Source Kit (the latest version is Devcon DDK 1.0) is a
tool available to device driver developers which has sample source code for
various types of drivers.  To order this product, please call 1-800-633-8266.
Once you receive the product, you should find additional information on tools
required to compile the source code.

In addition, IFS.ZIP and IFSSRC.ZIP are files available in the Main file area
on the DUDE.  These files may be useful to you in your IFS development.




!STORAGE________________________________**********
April 07, 1995
QUESTION:  (Ref: GS8)
Our current package currently operates with most SCSI tape units via the
services provided by OS2SCSI.DMD.  As far as I know, there is no existing
equivalent for EIDE devices at this time.

Would there be anything in the IBM1S506.ADD driver which would prevent me from
using it to control an EIDE tape unit via IORBs?  I do have the DDK but didn't
see anything in the IBM1S506 source that would prevent me from doing this.

Assuming I could use the IBM1S506 driver, would I need to do this via a
basedev(.DMD) or could it be done via a regular PDD?


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




!OTHER__________________________________**********
April 07, 1995
QUESTION: (Ref: GS1)
One of the things I need to do to enhance our SCSI ADD driver is to add power
management support.  I got a lot of information from the I/O device driver
reference manual in the latest device driver kit (i.e.  the developer
connection DDK for OS/2 vol 1 ver 1).  However, I am not very clear on some
areas.  I am hoping you can shed some light on this.

1) To get the APM Device driver entry point, one uses the AttachDD device
helper service.  Is the entry point for the ring 0 selector valid for me to
talk to since the ADD driver is a ring 0 driver ?

2) The manual talks about registering the power management notification
routine during the INIT_COMPLETE routine.  I assume this is only for ring 3
PDD drivers not for ring 0 ADD drivers ?  Is this a safe assumption to make ?

These questions are based on Advanced Power Management Architecture chapter in
the I/O Device Driver reference.


ANSWER:
1. Your ADD will be loaded by OS/2 before the APM.SYS or VAPM.SYS.  The latter
drivers are installable (DEVICE=APM.SYS).  Therefore, you will not be able to
do an attach at INIT time.  The kernel will call the init complete strategy
routine (1fh) after all the DDs are loaded.  In this routine, your ADD can
attach to the APM driver in R0 and perform any IDC call.  To receive the
InitComplete Request Packet your ADD has to be defined as a Level 3 Device
Driver (this is not to be confused with Ring 3) and Bit 4 is set in the
Capabilities Bit Strip in the DD Header.

2. PDD strategy routines (except INIT) run at R0 and it is safe to do IDC.
Your ADD can register its notification routine in INIT_COMPLETE routine.

   Ref: AttachDD in PDD Reference




!BASE___________________________________**********
April 07, 1995
QUESTION:  (Ref: GR4)
This will be a driver for a piece of custom hardware that will collect analog
data, convert it to digital, and store it in a FIFO resident on the board.
The device driver will retrieve the data from the FIFO (which will be mapped
into the I/O space) and store it in local buffers for access by the
application software.

The driver's local data buffers need to be large, and are causing the primary
data segment to exceed 64K.  To handle this, I am allocating these buffers in
a separate data segment.  It is my understanding that only the primary data
segment is guaranteed to be locked and that any other data segments must be
locked to insure that they cannot be swapped.  However, when I attempt to lock
the segment for these buffers, the call fails.  Specifically, I am doing the
following:

The driver data buffers are allocated in a separate data segment:

        char _based(_segname("_DATA1")) buffer1[20000];
        char _based(_segname("_DATA1")) buffer2[20000];
        char _based(_segname("_DATA1")) buffer3[20000];

The linker map file verifies that this works - these buffers are allocated in
a secondary data segment.

At driver initialization, the first thing I do is lock the segment in which
these buffers reside:

        ULONG handle;
        DevHelp_Lock(SELECTOROF(buffer1), LOCKTYPE_LONG_HIGHMEM, 0, &handle);

But this call fails (returns non-zero).


Q1:  Can you explain what I am doing wrong?

A1:  DevHlp_Lock is similar to the old style (16-bit) devhelp function in OS/2
1.x.  In order to support old device drivers developed for OS/2 1.x, which
require segment locking, this function is available in 2.x.  It is a very
expensive call to emulate in a 32 bit OS which supports paging.  It assumes
you want memory below 16MB and contiguous (as required in 1.x) and hence the
call may fail if it is unable to get contiguous memory below 16MB.  We suggest
you use the 32-bit version of the call namely DevHlp_VMLock.  Ref:  PDD
reference.
==============================================================================

Q2:  How can I insure that data allocated in the secondary segment will not be
swapped?

A2:  To ensure that your segment is not swapped you can use the VMDHL_WRITE
option in the flags parameter of DevHlp_VMLock.

                                OR

In the module definition file (.DEF file) you can specify your data segment as
FIXED to prevent moving/swapping.
==============================================================================

Q3:  Using VMLock to fix the segment in memory appears to work, however it
would be preferrable to use the module definition file and the FIXED option to
the SEGMENT statement so that the lock does not have to be done at run time.
However, I did not consider this an option since Microsoft's documentation on
the linker indicates that this is ignored under OS/2.  Specifically,
Microsoft's Quick Help in discussing this option to the SEGMENTS statement of
the module definition (.DEF) file says:

      -----Movable Data Attributes------------------------------------

      These attributes determine whether a segment can be moved around
      in memory:

      MOVABLE   The segment can be moved in memory.

      FIXED     The segment is fixed in memory (default).

      This field is ignored by OS/2 (under OS/2, all segments are
      movable) but is provided for use with real-mode Windows.

      -----Movable Data Attributes------------------------------------

Can you comment further on this?  Is this option now recognized by OS/2?  Is
FIXED or MOVABLE the default under OS/2 3.0?


A3:  Refer to the Microsoft C Version 6.0 Ref.  Manual.  In the SEGMENTS
statement in the .DEF file, the MOVABLE | FIXED Option is not supported on
OS/2.  This is also not supported on Warp.

You could however make the segment Permanent by including the following in
your .DEF file -

            SEGMENTS DATA1 CLASS 'DATA' IOPL.

A permanent segment remains after initialization and is Movable & Swappable
but not Discardable.

You could then use Lock/VMLock to fix it.
==============================================================================

Q4:  Is there a way to verify, at run time, that a segment is not being
swapped or is not swappable?

A4:  As far as we know, there is no way to determine the Segment Attributes at
RunTime.  Since the .DEF file controls the segment attributes, you could
probably use this info to determine the Segment Attributes beforehand.




!OTHER__________________________________**********
April 07, 1995
QUESTION:  (Ref: GR3)
I'm interested in any hints relative to getting started writing a card
services client driver.  I've looked at the samples, clsample and cldfm, in
the ddk.  Also, I have Steve Mastrianni's book.  One specific item I'm curious
about is, looking at the cldfm sample, it appears that it would be usable with
minimum changes for new modem cards or even audio cards.  Is this true, or am
I missing something significant here?


ANSWER:
The client driver sample codes in the DDK are not working codes.  They are
just samples to begin with and you will need to make modifications to suit
your requirements.  They are basically skeleton codes which require you to
work on them to get the code working with your Modem/Audio Cards.




!OTHER__________________________________**********
April 07, 1995
QUESTION:  (Ref: GO1)
I have TOOLINFO.INF from the DevCon, but this is the only documentation I can
find on LINK386.  By experiment, I have found that it is possible to link a
PDD with LINK386, and these seem to work.  Even "/exepack:2" works fine, which
allows LZ compression of the target.

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

I assume that a segment marked "PERMANENT" is non-swappable but is moveable,
while a segment marked "RESIDENT" is neither swappable or moveable.  If I mark
a segment as both "PERMANENT" and "RESIDENT," this is interpreted by EXEMAP as
"CONTIGUOUS."

1. Am I right about all of this?

2. Are there additional useful keywords?


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

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




!OTHER__________________________________**********
April 07, 1995
QUESTION:  (Ref: GI9)
I am writing PCMCIA card enabler device drivers for OS/2.

I have already written a "direct" enabler for the Intel controller which works
well.  I am now writing a card services client enabler which will operate with
any PCMCIA card services.

I have tried to interface to the IBM supplied card services driver according
to the PCMCIA specified protected mode OS/2 Intel 80286 processor bindings.
This just hangs the PC.


Q1:  How do I invoke IBM card services?  I have tried a FAR CALL to the
opmEntry but this is what hangs the PC.

A1:  You are probably not setting up the DS.  AttachDD returns the DS of the
IDC Device Driver.  The IDC entry point of the PCMCIA Driver follows the Far
Call/Return Model.  You could use the Kernel Debugger to verify the
Parameters, after you invoke AttachDD.
==============================================================================

Q2:  Also, I understand that OS/2 Warp has a device driver install program
which requires a data file on the device driver diskette to help install the
new device driver.  I understand this is a .DDP file.  Can you specify which
files you want to load after and/or before?

A2:  Refer to the Physical Device Driver Reference - Chapter on Installation
of External Loadable Device Drivers.

You cannot specify some files to be copied at the first attempt and the rest
later on.  In your DDP file, in the :FILES section, specify the source &
destination.  For example it could be:

         :FILES
         filename.OS2 \DESTINATION\filename.OS2
==============================================================================

Q3:  I have looked at "The Developer Connection" CD which has the PCMCIA
source code for a COM port card services client.  I noticed that the STRATEGY
procedure has 2 cases, 1 for an INIT packet (id = 0x00) and one for an
INIT_COMPLETE packet (id = 0x1F).

I have the OS/2 2.0 Technical Library Physical Device Driver Ref.  and Mr.
Mastrianni's superb "Writing OS/2 2.1 Device Driverss in C" book, but neither
make reference to the strategy command (0x1F).  Is this new to OS/2 version 3?

A3:  The Initialization Complete Command is documented in the Physical Device
Driver Reference (See Physical Device Driver Strategy Commands section, then
Summary of Strategy Commands section, then you should find the Initialization
Complete - 1FH command.  Besides this, there is a brief description in the
book by Mastrianni - "Writing OS/2 2.1 Device Drivers in C" (See page 92).
Both these references are available on the DevCon DDK Version 1. This command
is not unique to Warp.
==============================================================================

Q4:  I find that I can get the DDHelp entry point, find the card services
driver with the DDHelp "AttachDD" function and parse my CONFIG.SYS parameters.
But as soon as I try to call a card services function during the INIT (0x00)
strategy command, I get a system halt with the register display.  Any ideas
why?

You mentioned before that I had not set up DS.  I notice the sample code
supplied on the DDK does NOT do this!!

A4:  The CLDFM Samples that you referred to have to set up the DS before
invoking the IDC Entry Point.  This is a defect in the samples COM_IDC.ASM &
CS_IDC.ASM.  We will fix these defects in our next release.  We are sorry if
it has caused any confusion.
==============================================================================

Q5:  Can I only call card services after I receive the INIT_COMPLETE packet?
I have set up the DD to respond to this but I never get hit by this packet
from OS/2.

A5:  You can call the card services only after you receive the INIT_COMPLETE
Packet.  To receive this Packet, ensure that your device driver is a level 3
device driver & Bit 4 is set in the Capabilities Bit Strip in the device
driver header.  The INIT_COMPLETE Request Packet informs your device driver
that the Card Services has been initialized and you could go ahead and
establish the IDC.
==============================================================================

Q6:  I have managed to initialize my device driver on the INIT (00h) packet
and registered with card services on the END_OF_INIT (1Fh) packet.  When I run
up OS/2, I can insert my PCMCIA card and it will be successfully recognized
and configured by my card services client.  However, if the card is already
inserted on boot-up, my card services client cannot configure the card.  When
a client registers with card services, an artificial CARD_ INSERTION event is
generated.  It appears that when this is happening on boot-up, the IBM client
(AUTODRV.SYS) is getting notification of the event first.  As a result, the
card is rejected by the IBM client and our client rejects the card too.  I do
not know why.

It does not matter which device is loaded first in the CONFIG.SYS, this always
happens.  But when I generate a real CARD_INSEERTION event, by physically
removing the card and re-inserting it, my client successfully configures the
card.

My CALLBACK handler routine is the same for both cases as they are passed in
the same from card services.

Is this a familiar problem?  I need to get the card enabled from the
CONFIG.SYS as our users may load their network drivers from there too.


A6:  Does your driver loop waiting for a Card Services REGISTRATION_ COMPLETE
message during INIT command processing?  If so, then you may be running into a
problem which we have help for documented below:


      Etherlink III problem.

The problem with the etherlink driver is it requests resources in an interrupt
routine.  This is how it happens, Card Services calls into the etherlink
drivers IDC entry point with a Card Insertion event at interrupt time.  At
this point, the etherlink driver calls into card services asking for
resources.  Due to a change in design you cannot ask for resources during an
interrupt handler routine.  Card Services fails the request for resources and
therefore the etherlink driver fails initialization.

      Solution.

This problem will only occur for drivers that loop to wait for Register
Complete.  Here is what needs to be done so that Card Services will not call
the IDC of the client driver at interrupt time.  In the client driver, move
RegisterClient to the Init_Complete code.  This will force the register client
to be be at ring 0 instead of ring 3 as in the init command.  At the end of
the init_complete, do not loop on register complete.  Instead, issue a
proc_block.  In the IDC, under registration complete, issue a proc_run command
to finish the init_complete code.

      init_command:
          Parse INI file
          Save DevHlp entry point
          DevHlp_AttachDD (CardServices)
          return(success)


      init_complete_command:
          registerclient;
          Devhlp_ProcBlock(BlockID);  /* put -1 in timeout high and
                                                      low, set interruptable */
          return(success);

      Registration_complete
          if (BlockID !=0) Devhlp_ProcRun(BlockID);
          return(success);
==============================================================================

Q7:  My driver does not call *any* card services during the INIT command
processing.  I do, however, during INIT_COMPLETE.  My driver does wait for
REGISTRATION_COMPLETE after calling card services with a REGISTER_CLIENT
request.  When I get the REGISTRATION complete notification, I complete the
INIT_COMPLETE and return to OS/2.

I only REQUEST_RESOURCES from card services when I get the CARD_INSERTION
event on CALLBACK.  Does this mean that if I issue REGISTER_CLIENT and I get
the CARD_INSERTION (artificial) event before the REGISTRATION_COMPLETE
notification that the driver will fail?

A7:  In my last response I asked if the client driver was looping in the code
or using the DevHelp Proc_Block/Run functions during its Init_Complete
processing waiting for the Register_Complete event.  The bottom line is that
looping is problematic and should not be used.
==============================================================================

Q8:  Is there any way of getting the AUTODRV.SYS program to recognize and
configure 3rd party cards?

A8:  Are you working on DOS or OS/2?  The DOS driver is named AUTODRV.SYS and
the OS/2 version is named AUTODRV2.SYS.  They work differently, which is the
reason I ask.  For instance, the DOS version will auto enable a card which it
doesn't directly support whereas the OS/2 version will not.
==============================================================================

Q9:  I am now writing a card services client for OS/2, so the EZ-Play client
is AUTODRV2.SYS.  My question with regard to the EZ-Play AUTODRV.INI applies
to both OS/2 and DOS.  Can it be set up to recognize and configure *any*
PCMCIA card?  My card services client for DOS works fine, either at BOOT or on
card insertion.

A9:  The OS/2 version of AUTODRV2.SYS does not yet support the ability to
recognize and/or pre-configure CardIDs beyond the class of Modem/Fax devices.
We expect to have a beta version of this support available in the near future.
However, to support your card on existing Warp for Windows and Warp with
Windows products, you will need to write an OS/2 version of the PCMCIA Enabler
client which is what you are doing.
==============================================================================

Q10:  One problem I cannot seem to clear is that when the INIT command is
passed to the driver, the request packet contains a pointer to the entry point
to the DevHlp interface.  Is this still valid when the INIT_COMPLETE command
is passed in?

A10:  Yes, the provided address is always valid.
==============================================================================

Q11:  When the client calls card services with a REGISTER_CLIENT call, does
the REGISTER_COMPLETE or CARD_INSERTION event happen first?

A11:  Artificial Card_Insertion events are generated (for cards that were
present before the client registered) before the Register _Complete event.
Once registered, Card_Insertion events are generated real time with the
physical card's insertion into the socket.
