Device Driver FAQ

By IBM

This is file: QUESTION.TXT - Answers to previous questions

This file is divided into areas of special interest. Areas are separated by a heading line. Each heading line contains a unique string of characters. A search for the unique string will allow you to find the area of interest without having to scroll through the entire file.

General Device Driver
OCTOBER 27, 1993 - G0032

1) It would be VERY helpful to have an API to grab the NMI just like there are for the normal IRQS. We have an application that must get immediate notification, regardless of the IRQ state. Windows has a defined interface that we use.
 * QUESTION (Ref 572)

The functions would probably be something like:

SetNMI, UnSetNMI and a DismissNMI.

All this can be done at ring 0, but it would be nice if there were an API to do it.

Ring 0 code can register to get control on an Interrupt from a particular IRQ - effectively the code registers as an interrupt handler. There is no equivalent Ring-3 interface.
 * ANSWER

NMIs are not like IRQs. NMIs are TRAPs, like executing invalid instructions. There are 4 reasons for NMIs. Parity error on the planar, Parity error on an adapter card, Channel DMA Timeout, Watchdog Timeout. I can not envision why we would want to give an application or device driver control for any of the 1st 3` failures.

My guess is that Windows has an API to handle the 4th, Watchdog Timeout. A Watchdog timeout says that some piece of software has stayed disabled past a specified time.

The system state at NMI is disabled for all interrupts, ring-0, running under the trap handler. In windows, an application may disable. In OS/2, Ring-3 apps do not have that capability.

It would be interesting to understand how valuable this API is to Ring-0 code. I do not believe there is any chance we would risk system stability by giving a Ring-3 app control out of the Trap handler.

June 28, 1993 - M0010


 * QUESTIONS (Ref 272)

1) What are the changes to the format of the number and format of the parameters used by the category 1 DosDevIoctl functions? Are there any changes to the format of the Request Packet sent by the kernel to the device driver (OS/2 2.x vs. 1.x)? If so what are they?

2) It appears there has been a change made to the number and format of the parameters used in the DosDevIOCtl calls. OS/2 1.2 rc=DosDev IOCtl (datapacket, parm packet, category, function, handle) OS/2 2.0 rc=DosDevIOCtl (handle, category, function, parm list, parm length max, parm length inout, data area, data length max, data inout). The 2.0 information is from the "IBM C++ Beta / IBM Class Collection" on line help.

When did this change take effect? The earlier response to this question states there is no difference between 1.3 and 2.x.

Did this happen between 1.2x and 1.3?

Does this change affect the format or content of the request packet sent from the kernel to the device driver? If so, what?

3) What is necessary to migrate to, or develop from scratch, a 32 bit model device driver for OS/2 2.x?


 * ANSWERS

1) There are no differences between 2.X and 1.3 in the format of DosDevIOCtl Category 1 functions.

2) The earlier answer refers to the interface between PDD's and the Kernel. The customer mentioned the difference in DosDevIOCtl. The DosDevIOCtl interface which the customer saw in OS/2 1.2 reference is a 16-bit interface, and the one in the OS/2 2.0 reference is a 32-bit interface. On OS/2 2.0 and 2.1 there still exists a DosDevIOCtl 16-bit interface that is the same as the one on OS/2 1.3 and 1.2. This allows the application program or the test program using the DosDevIOCtl 16-bit interface to be compatible with OS/2 2.0.

Maybe the customer is talking about the difference between the parameters for OS/2 1.2 and OS/2 2.0, Even on OS/2 1.2 DosDevIOCtl2 already was there, and it is an equivalent API to OS/2 2.0 32-bit DosDevIOCtl which has length fields. The difference is controlled by the kernel. In the device header, there is a device driver level. If it is less than level 2, the kernel does not pass the length fields to the device driver. If the device driver marks level 2 or more in that field, it must support receipt of a request packet with the associated length fields. As far as I checked, the CP Programming Reference, versions 2.00 and 1.3 of OS/2 technical library, that difference is from OS/2 1.2. So I do not think that there is any difference between 1.3 and 1.2. (Please refer to page 2-68 of the CP Programming Reference of the OS/2 2.0 Technical Library.)

By the way, on DDK #2 due for release May 25, there is an INPUT/OUTPUT device driver reference. The chapter Physical ASYNC Communication Device Driver will be helpful for this customer.S

3) In OS/2 2.0 and 2.1, there are no 32 bit physical device drivers. The Request Packet interface from the kernel and Device Helper function interface are 16 bits. 32 bit is not supported yet. The customer can have the thunk function, but it is very expensive development, and the performance will be much worse than 16 bit one. We recommend writing the device driver in 16 bits.

May 3, 1993 - G0031


 * QUESTIONS: (Ref: 174)

1) Describe the "adDevCapsData" structure defined by the OS/2 driver, and how it is related to the appearance of the PM desktop?

2) Please define the surface structure as defined in driver.inc. For example, there are overlays which act as unions, that's pretty clear; but under which circumstances (which calls), etc.

3) We get some "recording error" messages from the kernel debugger. "GRE: Recording Error: PM=207c   DOS=0"
 * is there a log file with some helpful info?
 * where do we go to get the 207c's meaning?

1) In PM Programming Reference of Technical Library, there is specification about DevQueryCaps. "adDevCpasData" structure is for this call. There are many elements which is the device driver's capabilities, like the number of colors supported, resolution, default font size.. etc. The customer can check each element.
 * ANSWERS:

2) The overlayed parameter
 * sd_pbmi:pointer to bitmap information. (It is on of the input parameters which caller sets) It is set in DrawBits (WINBITS.ASM) call.
 * sd_pClrTab:pointer to color mapping table. It is also set in DrawBits, but in source code (WINBITS.ASM) sd_cySeg, which is another name of this area, is used to set pointer.

Original parameter Surface structure used for function related with BITMAP. When the customer follow up or debug the BITMAP functions source code they will know more. In Presentation Driver Technital Library, they can see the functions categorized as bit-map function. Actually about struncture, explanation is in DRIVER.INC.
 * sd_dScan:It is set in DeviceCreateBitmap call (BMSUP.ASM) and ImageData call (WINBITS.ASM)
 * sd_cbFill:It seems it is not used.
 * sd_cySeg:It seems it is not used. (Only the place where it is used is for setting color mapping table.)
 * sd_SelIncr:It seems that it it not used.

3) The error number is in the following header files.

For PM error .\DDK\H\PMERR.H .\DDK\INC\PMERR.INC For DOS error .\DDK\H\BSEERR.H .\DDK\INC\BSEERR.INC In this customers case, PM=207C means PMERR_INV_HDC (Invalid HDC).

May 3, 1993 - G0028


 * QUESTION: (Ref: 213)

COMPRESS/PACK UTILITY

The installation procedure uses the unpack utility program to copy files from the distribution diskettes. Where can I find a copy of the PACK utility I can use that will produce compressed files recognized by the program unpack.exe. If the PACK program is unavailable, how can I change the installation procedure to use a different program for the decompression?


 * ANSWER:

The tool is OS2PACK. This tool is an internal tool and is not available to anyone outside of IBM. He should use something else. His driver will not be unpacking at the same time as OS/2 anyway, unless he knows something I don't about how to get his driver on the base system diskettes!

April 5, 1993 - C0026

In the latest PDK it documents the new strategy command 0x1F (complete init). What state is the driver in when it receives this command and what helpers or routines can the driver use?
 * QUESTION: (Ref 209)

The driver is at ring 0 and has access to all DevHelp routines documented for PDD.
 * ANSWER:

March 29, 1993 - C0025

Could you tell me if OS/2 2.0 guarantees that the physical address entries in the scatter/gather lists operate on a minimum of a dword (32 bit boundary) i.e. xxxx xxxx xxxx xxxx xxxx xxxx xxx0 0000.
 * QUESTION: (Ref 100)

We are working with a company developing a SCSI product and they want to provide us a controller with a scatter/gather element resolution of DWORD instead of a single byte boundary. This means that the SCSI product will only be able to transfer data on a dword (32 bit) boundary.

Are we going to have to jockey our code and allocate a 4 byte buffer to make this work?

There is no guarantees that the addresses returned in a scatter/gather list will be on a dword boundary. Sorry, looks like you will need to do that jockeying.
 * ANSWER:

March 23, 1993 - C0023


 * QUESTION: (Ref 077)

I am interested in porting a Windows DLL to OS2 that will provide services to native mode OS2 applications, DOS applications and Windows applications. The DLL in question implements a proprietary HP virtual terminal protocol that will require the services of IBM's TCP/IP stack. The DLL will then be used by a terminal emulator to provide terminal and file transfer services.

I have 4 questions:
 * is it possible to provide such a service?
 * if so, what is the recommended architecture?
 * is there any documentation or sample code available for implementing such an architecture?
 * will there be any performance problems associated with the architecture?


 * ANSWER:

Yes, it is possible to provide such a service. Obviously since the DLL is being ported to OS/2, OS/2 applications will not have trouble accessing it. That leaves us with how to support Windows and DOS applications. The suggested method is to create a VDD and an OS/2 service application that work together to pass requests from the VDM world to the OS/2 world. At system startup time the service application should begin its work by setting up and calling the VDD. When inside the VDD, the service application thread should block itself on a semaphore and wait for the VDD to signal that it is needed. Now let's jump ahead to when the Windows or DOS application is running and needs to make use of the DLL. The senerio goes as follows.

The VDM application makes a request to the VDD via an interrupt. Once in the VDD the VDM application thread should identify the work to be done, unblock the service application thread, and then blocks itself using VDHWaitVIRRs (Blocking the VDM thread using VDHWaitVIRRs insures that the VDM applications still receives all simulated hardware interrupts while waiting on completion of the DLL service). The service application thread comes alive and while still in the VDD, passes any VDM to DLL data to the OS/2 service application either using a buffer or using shared memory (The rule of thumb is use a buffer for passing data blocks under 4k and use shared memory for passing blocks of data greater than 4k).

Next, the service application should fall out of the VDD and back out to OS/2 ring 3 land where it can process the request to the DLL. After completing the DLL service, the service application thread should pass back any DLL to VDM data and call back down into the VDD. Returning to the DLL, the service application thread should clean up and setup the VDM application thread for operation, unblock the VDM application thread, and block itself to await the next time it is needed for VDM to DLL communication. That's all there is, now all you got to do is write that code.

This method for VDM to DLL communication is the same method used for seamless Windows support. Documentation and source code for construction of this communication system is rather limited. For instance, while seamless Windows code is available in the current DDK, the seamless VDD is not available and will not be made available (it is considered part of the kernal). There are VDD samples available, though. As for the performance question, the above scheme is prefered due to its good performance.

February 26, 1993 - C0019

How can I issue error messages from a device driver after initialization time?
 * QUESTION: (Ref: 140)

Create an application that can call the device driver using a user defined IOctl call. When the application is ran it should call the device driver and the driver should block the application's thread on a semaphor. When it becomes necessary for the driver to issue an error message, then it should write the message to a buffer, awaken the block thread, and the blocked thread should return to its application with the message buffer.
 * ANSWER:

The application can then issue the message and recall the driver through the IOctl to be blocked once again. It has been suggested that the best way to print the message from the detached process is to use a VIO popup screen, this functionality is documented in 1.X manuals.

How can I keep the end user from being aware of my detached application? Most users will not mess with the driver setups found in config.sys but how can I make sure a user won't mess with application start ups found in startup.cmd?
 * QUESTION:

Application startups can be written into config.sys. For the application discussed, the following line in config.sys would start it up. RUN=C:\MYUTILS\MY.EXE
 * ANSWER:

February 26, 1993 - C0018

The following functions are described in the VDD manual however there is no explanation as to what the real purpose of these functions are: VDHDecodeProperty  VDHQueryProperty   VDHRegisterProperty
 * QUESTION: (Ref 099)

All the VDHXXXProperty routines are used to setup/maintain/manipulate the DOS Settings for VDMs. VDHRegisterProperty allows a VDD to create a new DOS Setting, for example.
 * ANSWER:

What is interrupt simulation for VDDs?
 * QUESTION:

The interrupt service routines of VDMs do not get called during the real hardware interrupt processing (pre-EOI). The hardware interrupt gets scheduled for the VDM and SIMULATED to it at some later task time. This process is called interrupt simulation.
 * ANSWER:

What are the explanations for the priority classes (VDHSetPriority) and why can't a VDM session change from a higher to a lower priority correctly?
 * QUESTION:

VDMs are a special beast in OS/2. I suggest NOT changing their priorities at all. Since multiple VDDs can change the priority of a VDM, the handling of the begin/continue/end use flags is handled by using the highest priority that is still in use. If my VDD asks for a low priority but yours asks for a high one, your request "wins".
 * ANSWER:

NOTE: any developer out there who feels they must use VDHSetPriority should please call the OS/2 Device Driver Developer's support group and discuss their needs.

Can the Dos idle settings be used to affect the priority of a VDM?
 * QUESTION:

No. These settings are for describing to OS/2 the likelyhood of how much the VDM application is in an idle state (doing useless stuff). The information is used by OS/2 to judge when to shoot a VDM application and let other processes have some time.
 * ANSWER:

I am developing a system where multiple VDMs are communicating through multiple VDDs to my specialized hardware. One of the VDDs is completely incharge of processing the interrupts. The environment is real time and I need the fastest performance possible of the interrupt handling. Currently when a request is made from a VDM session to one of my VDDs, the VDM thread is frozen, the request is sent to the VDD doing interrupts via IDC, the request is processed, the result passed back to the VDD who first took the request, and the VDM thread is thawed. The bottom line is that my VMD thread doesn't seem to have enough priority and is slow to return to operation after the thaw.
 * QUESTION:

Freeze and thaw have overhead and a thread that is being thawed does not get awaken that quickly. A better implementation would be to block the VDM thread on a semaphore (see VDH services set and reset) and when interrupt processing is complete simply unblock the thread. The thread will then immediately become available for execution. The other benefit is that the blocked VDM can still process interrupts sent to it while a frozen VDM can not.
 * ANSWER:

When using DosStartSession (documented in the Control Program Programming Reference, page 2-343) to start a Dos session (SessionType equal to 4 or 7), I was told I could set my Dos environment variables by placing the appropriate string in the Environment string. For some reason strings involving on and off have no effect. For example, the string "COM_HOLD=ON" doesn't work, the COM_HOLD remains at its default of OFF.
 * QUESTION:

Instead of using ON and OFF, use 1 and 0. For example, "COM_HOLD=1".
 * ANSWER:

Will VDDs developed for OS/2 2.0 need to be recompiled with 2.1 headers to work properly under OS/2 2.1.
 * QUESTION:

The necessity to recompile previously designed VDDs is not anticipated. In fact some the VDDs being released with OS/2 2.1 are unmodified 2.0 versions.
 * ANSWER:

February 23, 1993 - B0002

I have two questions regarding the 16 meg boundary. We are developing a add to support all ISA/MCA and EISA scsi host adapters.
 * QUESTION: (REF:135)

My first question: If I report that the host adapter does not support more than 16 megabytes in the get device table in the Adapter flags field, does the DMD and/or Kernel gaurantees that all the read/write request buffers are below 16 mb address. The reason for asking this questions is, whether add should check the requests physical address for 16mb physical boundary?

My second question: For certain scsi host adapters, the CCB physical address should be below 16 meg. During the alloc_phys call, I can either specify below 1meg or above 1meg. Is there any performance impact on the system, if I allocate large amounts of memory below 16 meg? Is there any other way to get the memory below 16 meg?

All allocations done thru 16 bit devhlps (that deal with memory, ie allocphys, lock etc) will return buffers below 16 meg. 32 bit devhlps (i.e. vmalloc) allow the caller to specify if they want (need) memory below 16 meg. If the adapter flags field is set to not support greater than 16 meg, the kernel will force allocations to be below 16 meg.
 * ANSWER:

If the device locks the read/write request buffers, there is no need to check what the physical address is, since the lock call itself will force the physical address below the 16 meg boundary. If the buffer are not locked or locked by another device the test will be needed.

AllocPhys will always return physical addresses below 16 meg. Allocating large amounts of 'physical' memory will always impact the system, regardless of where they are. Below 1 meg is worse than below 16 and below 16 is worse than greater than 16, as far as system performance is concerned with respect to physical allocations. I don't understand the last question. If it's talking about a device driver allocating physical memory, there are two ways; 1) the 16 bit allocphys call and 2) the 32 bit vmalloc call.

February 23, 1993 - B0001

We have four questions regarding using Dosxxx api calls. We need to display messages from the add during the task time and interrupt time after Initialization. We know that we can not use DevHelp_Save_Message after initialization. We also realize that we can not make Dos api calls during base driver init time.
 * QUESTION: (Ref: 140)

1. Can we use dosapi call DosPutMessage during task time and interrupt time from the add?

1) No, physical Device Drivers are only able to use the DEVHELP API's after INIT time.
 * ANSWER:

2. In which library are dos api calls built in?
 * QUESTION:

2) Available from PDK but once again only good for applications.
 * ANSWER:

3. How do they interface with the kernel?
 * QUESTION:

3) Ring 3 call gate.
 * ANSWER:

4. Is it the same way as DevHelp calls?
 * QUESTION:

4) No, DEVHELP is a single call gate at RING 0.
 * ANSWER:

February 16, 1993 - C0016

I've recently come upon a serious problem using OS/2 2.0 and trying to call the ROMs of our accelerator cards. Under OS/2 1.n I was able to allocate an LDT and call the ROM services. But with OS/2 2.0 allocating LDTs at certain locations (e.i. c680:0000) fails, I think this is related to 4K page boundaries & 80386s. This isn't such a horrible problem on ISA, EISA buses since the install program can change the ROM address. But on MCA buses where the ROM is at a fixed location of c680:0000 I'm unable to access the ROMs to support non standard resolutions or colour depths.
 * QUESTION: (Ref 014)

Is there a way to allocate on non-4k boundaries ? I've tried to allocate on a 4K boundary and adjust the address to point to the correct entry points but all our current ROMS are position dependent on the offset and seriously crash OS/2 2.0 when called in this fashion.

It seems (from the information provided in the preceeding notes) that the driver needs its selector:offset tobe selector:0. If this is true, then a LDT selector won't be sufficient. In 2.0, LDT selectors are tiled and thus start on a page boundary. If you require a non-page aligned selector it will have to be a GDT selector, allocated by device driver. In such a case, it should be noted that OS/2 does not guarentee a zero offset on returned values from such an allocation.
 * ANSWER:

February 16, 1993 - C0015

1. I need to get EISA configuration ( BIOS INT 15h function D8h in DOS) how I get it in os2?
 * QUESTION: (Ref 139)

Chapter Seven in "IBM OS/2 2.0 Original Equipment Manufacturers DASD and SCSI Device Driver Support" (BBS File: OEMBASE.ZIP) describes and existing device driver (TESTCFG.SYS) that can be called to obtain a list of all EISA IDs. Is that what you are looking for? The interface described in the manual is for an application wishing to make requests for the information.
 * ANSWER:

I am investigating whether or not this device driver can be call via IDC, thus supporting the access of this information from within a device driver.

1. I have board that maped to addr 10C00000h the map size is 4MB how I do it so my process can read and write to this buffer (What DevHelp Service and how to used them)?
 * QUESTION:

The answer to this question is, "it depends on what you are trying to do." If you are trying to map this physical memory into a process' linear memory then from the device driver the DevHelp calls PhysToUVirt and PageListToLin can be used. PhysToUVirt tends to be used the most since due to the current tiled memory design it supports both 16bit and 32bit applications and since the PDD environment is a 16bit environment anyhow.
 * ANSWER:

Note though, each of these routines can only map 64K or less bytes at a time. If the device driver also needs to read from this same memory, the the above is OK for memory references from the device driver's strategy routine. If the device driver needs to read the memory from its interrupt routine then the memory needs to be made available either by using one of PageListToGDTSelector, PhysToGDTSel, or PhysToGDTSelector or by locking the pages down in the process to which they were mapped. If all that is desired is to move data from an application's linear memory space to the physical memory area of the adapter then the DMA method discussed below can be used.

2. Im also need to make DMA transfre between the buffer and the user buffer what is the best way to do it?
 * QUESTION:

The device driver can directly issues the commands to the DMA hardware and should do so using physical addresses. If the DMA is being initiated by an IOctl call then the device driver needs to lock the applications's linear memory, convert the linear addresses to physical values using LinToPageList or VirtToPhys, perform the DMA, and after completion unlock the locked memory. Note that the IOCtl call needs to break up the DMA request to match the underlying page structure of the application. When a large buffer (>4k) is allocated within an application there can be NO guaranties on that buffer being contiguous in physical memory. Consequently the device driver needs to determine the physical page boundaries and perform DMAs to fit what it finds. It is possible to have the device driver allocate and place in the application memory a physically contiguous buffer, but this type of activity is frowned upon being that it underminds the performance of the paged memory system.
 * ANSWER:

If, for a installable character device driver, the DMA is being initiated by a DosWrite or DosRead then the device driver will obtain directly a physical address to the memory region(s) already locked down.

If the original buffer is not contiguous then multiple DosXxxx calls will be generated automatically by the kernal so that only contiguous chunks are presented to the device driver. If, for a block or base device driver, the DMA is being initiated by a DosWrite or DosRead then the device driver will obtain a scatter/gather list to work with.

In both the IOctl case and the DosXxxx case the device driver can initiate the DMA and return to the application (IF THERE IS NO CONFLICT) or block (DevHlp_Block) until the DMA completes. The latter method is the recommended design. The device driver can hook the DMA's interrupt vector using DevHelp_SetIRQ so as to be made aware of when the DMA is complete.

If the device driver had blocked the application's thread then when the proper interrupt is seen in the driver's interrupt routine it can issue a DevHlp_Run to awaken the thread.

One last warning about the DMA approach, the operating system OS/2 can NOT see the DMA operation. Therefore OS/2 can not provide any protection from invalid DMA requests and any such bad requests will most surly cause the system to crash and burn. Please Mr. Device Driver Writer proceed with the utmost caution when developing a DMA based device driver.

February 9, 1993 - C0014

1. How I Use The Bios Service, for example Int 15h, from PDD?
 * QUESTION: (Ref 138)

A PDD cannot use BIOS services directly; PDDs must use a VDD in order to utilize the BIOS code. Please see AttachDD and the VDD reference manual for further details; please call after you investigate these materials.
 * ANSWER:

I'm curious; what INT 15H services do you plan to use? There may be a PDD that uses IDC in order to fulfill yours needs. Also did you investigate the DevHelp calls for the service you need?

Memory Allocation Problem
 * QUESTION:

1. I Allocate memory with the DevHelp Function VMAloc of Contiguous memory an also (Fixed all Time) from System memory e.g. GDT MOV ECX,Size ( 8000H KB) MOV EDI,-1   ;Not Initial With Physical Memory MOV EAX,0xA  ;1010b  (Contiguous,Fixed All Time) Then I call to LinToPageList to get list of pages but I got one page of the size 0x8000 KB (Allocated by VMAlloc) Instead of 8 pages of 0x1000 KB?

Since you asked for physically contiguous memory in your VMAlloc call, the kernel verified your request by indicating you had 8000h bytes in the response to the LinToPage call. Had you asked the kernel in the VMAlloc for discontiguous pages, then you would receive an array of 8 pages in your LinToPage call.
 * ANSWER:

Another way of looking at it: if the returned parameters from the LinToPage call was always in singular pages, there would be no need for pl_cb param.

FYI, OS/2 keeps track of physically contiguous memory with structures called arena headers; this information can be looked at with the kernel debugger with the .M command.

January 27, 1993 - C0012

Having problems with transfers of data >64K between an application and a device driver.
 * QUESTION: (Ref: 060)

1) If when using a DosDevIOCtl call, an address to a buffer greater >64k being passed through the data-address field results in an invalid parameter error, try passing the address through the paramter list instead of the data packet address field.
 * ANSWERS:

2) Some problems have been reported on passing >64K messages through message pipes. The important lesson learned by these reports is that the message buffers should be aligned data structures.

3) Just some background information: The way DosWrite and DosRead passes greater than 64K blocks is by first dividing up the blocks into less than 64K chunks and then repeatively passing the chunks until done. This operation can result in a performance penalty.

January 22, 1993 - G0012

In the process of building up the user interface of our VDD, we found two things that IBM VDD can do and we are not able to do:
 * QUESTIONS: (Ref: 046)

Question #1: Each property line in the DOS settings, IBM is able to display a description box as well as a help window. But we do not know how. What we can not do is to provide a description box/window as we highlight our property string with a mouse or the cursor. We are also not able to provide a help window when our property string is hilighted and the HELP button is selected.

Question #2: The second problem is with VDHPOPUP service. I have to use existing ERROR number/message # in order to use VDHPOPUP. The following is a code segment that we use to call VDHPOPUP. What we would like to do is to provide our own popup messages. The documentation says the it is similar to DOSGETMESSAGE but how do we use the MSG facility to append the messages to the end of the VDD?

Question #3: This question concerns the VDPPUSHINT and VDHPUSHFARCALL services. There is no documentation as to how the client register frame (CRF) is maintained. We do not want to save the complete CRF and yet we do want to resume our DOS application once the far call/DOS int is completed?

Answer to Q1: This cannot be done by a user written VDD at this time. It is a known requirement.
 * ANSWERS:

Answer to Q2: User defined .MSG files are not supported by VDHPopUp at this time. This is a known requirement.

Answer to Q3: The code which does the VDHPushInt or VDHPushFarCall (the VDD) is responsible for maintaining the CRF for restoration before the actual VDHPushXXX call and restoring it on the return hook or CSIP hook after the DOS routine has run. I would suggest VDHPushRegs/VDHPopRegs.

January 15, 1993 - C0010

Q1. The following functions are described in the VDD manual however there is no explanation as to what the real purpose of these functions are: VDHDecodeProperty  VDHQueryProperty   VDHRegisterProperty Q2. What is interrupt simulation for VDDs?
 * QUESTIONS: (Ref: 099)

Q3. Installing IO hooks (VDHInstallIOHook) causes a trap (0e) in SericePak and 11/92 2.x releases. The kernel debugger for 2.x and the GA release and kernel debugger works fine.

Q4. What are the explanations for the priority classes (VDHSetPriority) and why can't a VDM session change from a higher to a lower priority correctly?

1) All the VDHXXXProperty routines are used to setup/maintain/manipulate the DOS Settings for VDMs. VDHRegisterProperty allows a VDD to create a new DOS Setting, for example.
 * ANSWERS:

2) The interrupt service routines of VDMs do not get called during the real hardware interrupt processing (pre-EOI). The hardware interrupt gets scheduled for the VDM and SIMULATED to it at some later task time. This process is called interrupt simulation.

3) Installing IO hooks (VDHInstallIOHook) is done by just about every VDD shipped with the system. It works fine. Please inspect your code to make sure the call is being made during the correct context and is passing the correct parameters in the correct order.

4) VDMs are a special beast in OS/2. I suggest NOT changing their priorities at all. Since multiple VDDs can change the priority of a VDM, the handling of the begin/continue/end use flags is handled by using the highest priority that is still in use. If my VDD asks for a low priority but yours asks for a high one, your request "wins".

January 8, 1993 - C0009

I have another VDD PDD question. I am trying to get a PDD and VDD to communicate to each other through inter device communication. This means that I need to call the PDD from the VDD as well as the VDD from the PDD.
 * QUESTION: (Ref: 091)

In order to initiate the communication I call the PDD from the VDD using VDHOpenPDD. If successful this function returns a pointer (16:16) to the PDD's IDC function. VDHOpenPDD requires an entry point in the VDD so that the PDD can call the VDD.

The PDD is being written in assembly and compiled using Masm 6.0. The VDD is being written in C and compiled using C Set/2.

My questions are: Could you please provide some example code in C and assembly for the above question?
 * 1) The VDHOpenPDD prototype declaration is VDHOpenPDD(DeviceName, VDDEntryPoint), where Device name is a char * and VDDEntryPoint is a double. The VDDEntryPoint is a 16:32 entry. How would I declare the VDD entry function and how am I going to call VDHOpenPDD in order to pass the selector:offset of the VDD entry function? Is there any Pragma or any processor directives that will allow me to pass the 16:32 address of a C function?
 * 2) If VDHOpenPDD is successful, the return value is a 16:16 pointer to the PDD entry function.  How do I declare a prototype and call this 16:16 function using C Set/2?
 * 3) How will the PDD call the VDD with a 16:32 pointer? What is the exact assembly language instruction sequence to do this?

Thank you.

FOR THE VDD - In one file:
 * ANSWER:

Define the data area for the PDD entry point FPFNPDD PDFTPDDProc = (FPFNPDD) 0;      /* addr of PDD service rtn  */ Get the entry point to the PDD if ((PDFTPDDProc = VDHOpenPDD(szPDDName, VDFTPDDProc)) == (FPFNPDD)NULL) return FALSE;            /* return FALSE if VDH call failed */

Use the entry point (passing 3 parameters: function, pointer 1, pointer 2)

PDFTPDDProc(ENABLE_INTS,0,0);

In a seperate file:

Stop the compiler from doing BAD things int _dllentry=1;  // We must avoid standard DLL Library inclusion // /gp option was used in compilation // This option is protected DLL Define the entry point of the VDD SBOOL VDDENTRY VDFTPDDProc(ULONG ulFunc, F16PVOID f16p1, F16PVOID f16p2) {

}

FOR THE VDD MAKEFILE - Add /gp to the compile flags for the second source file

FOR THE PDD - Define the data area for the VDD entry point VTCAAddress df        0               ; HOLDS ADDRESS OF TCA VDD ENTRY POINT

Call the VDD .386P push  eax                       ;Function                        @VDD push  eax                       ;Pointer 1                       @VDD push  eax                       ;Pointer 2                       @VDD

call   FWORD PTR [VTCAAddress]                                  ;@VDD .286P Hope this helps.

January 6, 1993 - G0009


 * PROBLEM/QUESTIONS (Ref: 092)

Question #1: How can one implement the passing of a device number as in the case of a multiple serial I/O and parallel output port character device from the OS/2 2.0 caller to our PDD via the Strategy routine calls? Same applies to the Interrupt Handler?

Question #2: Our intelligent multiport character device requires its operating software be downline loaded during the system initialization phase. Is it possible for our startup code to access the file system to read in the operating code from a file during the system initialization? If so, how do you recommend a proven mechanism to achieve that?

Answer to Q1: Most character device drivers which support multiple devices use mutiple device headers to accomplish this. For example, COM.SYS has headers for COM1, COM2, COM3 and COM4. It has seperate strategy routines for each device header which push a parameter and call a common strategy routine. It has seperate interrupt routines for each IRQ which it must hook and uses the same (push and call common routine) idea for the different interrupts.
 * ANSWERS

Answer to Q2: As the Tech ref documents, there are DosXXX calls which are valid at init time. Two of the included functions are DosOpen and DosRead so, YES, data/code can be read from a file and uploaded to the adapter at init time.

January 5, 1993 - C0008

I have a very basic question about locking memory regions. If I do not need to access the memory object's physical address do I need to lock the buffer, i.e. if I am only accessing the buffer's virtual address, do I need to lock it? This is something which has not been clearly stated anywhere.
 * QUESTION: (Ref #76)

If one is not doing DMA with this buffer then one does not have to worry about locking it down. Although, if the memory is touched at interrupt time then the memory must be locked.
 * ANSWER:

December 15, 1992 - C0007

These questions regard OS/2 Adapter Device Drivers.

Does OS/2 ever request byte counts in a scatter/gather entry which are not multiples of 512?
 * QUESTION:

1.) S/G entries which span sector boundaries are not common but definitely do occur. If the adapter's S/G support is broken or limited, then the ADD should maintain a 64KB buffer to emulate S/G support for lists which are not acceptable to the adapter's S/G support.
 * ANSWER:

It is up to the ADD to scan the received S/G lists to detect when a transfer to the buffer is necessary. The ADD must also maintain appropriate controls to insure usage of the buffer is serialized in a multitasking environment.

If MaxHWSGList defines the boundary in a scatter/gather list where a sector will not be split across entries, how does OS/2 handle the case where a device driver returns a value of 1 for MaxHWSGList?
 * QUESTION:

2.) From my understanding setting MaxHWSGList to < 16 would either result in severe performance degradation or cause the OS/2 filesystems not to work at all. Our layer just passes this information back to the filesystems. You will need to discuss how the OS/2 filesystems handle particular parameter values with the owners of those components.
 * ANSWER:

November 17, 1992 - BK16002

In my config.sys, I have set priority = absolute. I have an application interacting with a device driver using semaphores for syncronization. There is also a background I/O activity. The controlling application activity clear the device driver semaphore and does a dosSleep(0).
 * PROBLEM/QUESTION

Is the device driver guareenteed to be scheduled next or could the background activity or any other activities be scheduled before the device driver? Does the device driver have a higher priority than the application activities? If not, what can be done to raise it to a higher level? The application activities are controlled by a DosSetPrty call;

Device Drivers do not own threads and, hence, do not have priorities. Processes own threads and can set the priorities of these threads by using DosSetPrty. DosSleep(0) yields the rest of a thread's timeslice to any ready threads of equal or greater priority (in the same or different processes) and is NOT gaurenteed to yield into the same process first. It is highly recommended that you do NOT use DosSetPrty.
 * RESOLUTION

October 28, 1992 - CJ280005

In the IBM OS/2 2.0 Toolkit, there is a sample VDD written in assembly. I am trying to build this sample virtual device driver so I can try allocating large pages. But I get the following error: Assembling: vdft.asm d:\TOOLKT20\ASM\OS2INC\basedef.inc(39): warning A4006: too many arguments in  macro call DefEntry(1): Macro Called From d:\TOOLKT20\ASM\OS2INC\basedef.inc(39): Include File d:\TOOLKT20\ASM\OS2INC\basedef.inc(40): warning A4006: too many arguments in  macro call DefEntry(1): Macro Called From I am using Masm 6.0. Can you give it a try and let me know if it works for you. The sample vdd is in the toolkt20\asm\samples\vdd directory.
 * Question:

The reason this is happening is because we (IBM) were a little rushed when we put out the toolkit. The VDD sample was originally going to be a C sample. But because of a problem with the C compiler, it was decided at the eleventh hour to make it an assembler program. It was further decided that the most popular assembler in the field at the time was MASM 6.0 which is the one we used. Unfortunately, the .INC files we had on hand were meant to interface with MASM 5.1 and some enhancements to 6.0 cause these warnings.
 * Answer:

Actually, they are only warnings and the sample will build correctly. If you want to experiment, you can play with the DefEntry macro that is defined in BASEMACA.INC.

Hope this answers your question. I played with it a little while to try to redefine the macro, but my MASM experience is limited and "duty calls" so I'll hope this suffices

Later.....

I am sending you an updated BASEMACA.INC file. It will correct those warnings your customer was getting on the VDD samples.

Note that this is an "un-official" version of the file.

October 28, 1992 - CJ280004

I am having trouble finding documentation on OS/2 2.0 IOPL segments. Under earlier versions of OS/2, IOPL (ring 2) stacks, allocated for DLLs, were set to a default size of 512 bytes, and the API call DosR2StackRealloc was used to increase the size of the ring 2 stack to something more usable.
 * QUESTION:

Where did this call go? (under 2.0 - I can't find any reference to it (or to IOPL segments in general) in my vast "OS/2 Programmers Library"). Is it still necessary?

Background: An IOPL segement is ...
 * FOLLOWUP:

An input/output privilege level executable section of programming code that enables an application to directly manipulate hardware interrupts and ports without replacing the device driver.

In OS/2 2.0, for new 32 bit applications and their DLLs, the concepts of IOPL and APIs for stack reallocations do not apply. This is flat memory model rather than segments. The memory manager for OS/2 2.0 handles stack expansions on reference.
 * ANSWER:

There is no equivalent REALLOC set of APIs in the 32 bit APIs. In terms of the documentation, the OS/2 2.0 documentation includes the new 32 bit APIs and all 16-bit APIs which had changes between OS/2 1.x and OS/2 2.0. Documentation for DOSR2STACKREALLOC is available in the documentation and Toolkits for OS/2 1.x

October 16, 1992 - BJ16001

1)

a) 1.3 Device drivers should work under OS/2 2.0 with a couple of exceptions. Most notably, DevHlp_PhysToUVirt may not return a zero offset even though the documentation for OS/2 1.3 says it the offset will always be zero. PhysToUVirt will page align (4K) the requests.

b) We changed the way base device drivers are loaded under OS/2 2.0. Under OS/2 1.3 there was a hardcoded list of base device drivers that were loaded (if present). Under OS/2 2.0, we minimized the list (CLOCK,KBD, and SCREEN) and allow you to load the base device drivers with a BASEDEV= statement in the CONFIG.SYS. More info on BASEDEV= is in the online Command Reference. Device drivers written to Microsoft's LADDR spec loaded automatically under OS/2 1.3, but must be loaded with BASEDEV= under OS/2 2.0. If your customer has problems with LADDR, they should contact Microsoft because it is a Microsoft product. Some of the names changed in their LADDR product for OS/2 2.0, so I don't think the product for OS/2 1.3 will work on OS/2 2.0. IBM has provided an alternate strategy for layered DASD device drivers, please see #4 below.

2) Base device drivers get called with a different strategy command (1BH) than loadable device drivers (00H)(loaded with DEVICE= statements), but the request packets are basically the same. The format of the the request packet for block base device drivers is documented in the OEM DASD spec (see #4 below).

3) Base device drivers are restricted to the same DevHlps at INIT time as loadable device drivers. Loadable device drivers can call a limited subset of the DosXxxx API, but Base device drivers cannot. One of the reasons for this is that base device drivers initialize at Ring 0 and loadable device drivers initialize at RING 3.

4) The OEM Device Driver Support Group in Boca Raton distributes the "IBM Independant Hardware Vendors DASD and SCSI Device Support" document. This describes the layed architecture that OS/2 2.0 uses for disk support.

Other vendors, for example Adaptec and Future Domain, used this document to write an "Adapter Device Driver" that interfaced to the OS2DASD.DMD (Dasd Manager). IHV's do not have to write an entire disk device driver, only the hardware specific portion (the ADD). There is a toolkit of sorts to go with this document. I'm not sure what is in it, but I think it contains sample code (code from one of our ADDs). If your customer is interested in coming to Boca to develop the ADDs, The Support Group should be able to help you out or at least point you to the right people. We encourage IHV's to write ADD's and do whatever we can to help them.

NOTE: The "IBM Independant Hardware Vendors DASD and SCSI Device Support" document is available for downloading from this BBS. It is called: OEMBASE.ZIP

CD-ROM
May 6, 1993 - M0001


 * QUESTION: (Ref 244)

How do we make an NEC CD-ROM CDR-36 drive read the OS/2 DDK CD on a MS-DOS 6.0 and OS/2 2.0 system


 * ANSWER: The NEC CD-ROM CDR-36 is supported by OS/2 2.1 Beta but not by OS/2 2.0. Obtain the OS/2 2.1 beta from (800)3IBM-OS2. For MS-DOS 6.0 help, contact Microsoft.

December 04, 1992 - BJ30001C PROBLEM/QUESTION

I am trying to establish ring 3 access to a dual ported, memory mapped i/o adapter, that resides at 0xd0000 and which is 4096 bytes in length.

I have had considerable trouble with my code using that function. Everytime I access that function, during init, the KDB indicates the wrong cs.

Everything seems to be ok, no errors are returned, but AX is allways 0 and in the SI register, I see what looks like the GDT selector with modified privilege bits set to 3.

Also, after leaving the init routine, the kernal returns right back to the init routine just like it was executing for the first time.

RESOLUTION

The change in the GDT slector seems correct since you are asking for ring 3 access and it is returning a ring 3 selector. The re-entrancy should not occur unless you have multiple device headers and are being entered for the next header.

January 4, 1993 - G0006 PROBLEM/QUESTION

When I issue "read long" function call (function 72h), I always receive an unknown command (return code ff03).

RESOLUTION

The IBM PS/2 CD-ROM - II Technical Reference that you are using applies to the newer IBM CD-ROM device. The older CD-ROM device does not support "read long" (block size of 2352).

November 2, 1992 - BJ30001A


 * PROBLEM/QUESTION:How can I get CDROM Programming information?
 * RESOLUTION:You can order IBM Personal System/2 CD ROM-11 (S10G-3359) Technical Reference from the Publications Order Department (1-800-426-7282)

DISPLAYS IN GENERAL
June 28, 1993 - M0008

QUESTIONS: (Ref: 258)

1) I have tried the following configurations with the results shown:

A) OS/2 2.0 Installed with 8514 as primary video and NONE as secondary video, although I am using a dual screen setup, 8514->Prim and VGA->Sec. I find there is no difference whether I specify secondary as VGA or none, Or is there?

i-- OS/2 works fine desktop on primary 8514, text (OS/2 full screen) works fine on VGA.

ii-- Copied our 16 bit display driver (based on your 8514 sources) to display.dll. This works properly, OS/2 desktop comes up on primary display in 1280x1024 resolution and text on secondary VGA.

B)Installed Service PAK on OS/2 2.0.

i-- Service PAK installs 8514 display driver as ibm8514.dll, OS/2 desktop on primary 8514, text on secondary VGA.

ii-- Copied OS/2 2.1 8514 (OS/2 2.1 beta DAK) display driver to IBM8514.DLL. This works properly, OS/2 desktop comes up on primary display in 1280x1024 resolution, text mode on secondary VGA.

iii-- Copied OS/2 2.0 8514.dll onto ibm8514.dll, OS/2 Desktop comes up on secondary VGA instead of 8514.

iv-- Copied our display driver onto ibm8514.dll, same as iii.

What, if anything am I doing wrong, (e.g. I have tried selective install) Is there a simple procedure I can follow?

2) Do I have to set up a description file, "*.DSC or *.DSP", and install using 'DSPINSTL'? If so, can you provide with a clear and concise sample file along with a procedure?

1) You need to run DSPINSTL. This utility updates the INI files to point to the new drivers, as well as installing them.
 * ANSWERS:

2) The DSPINSTL utility and procedures are available on the new DDK available May 25 for Spring Comdex.

June 28, 1993 - M0007

1) The base driver BVHSVGA.DLL accesses the following variables: SVGAHardware.AdapterType SVGAHardware.ChipType Although, my SVGA.EXE (in SVGAUTIL) identifies our custom chipset (like Tseng, Trident, etc.) correctly, but these variables after DosDevIOCtl are returned incorrectly. How are these variables set?
 * QUESTIONS: (Ref: 255)

2) What is the use of the utility: OEMHELP$ ?

3) I am having some problems during the compilation of Device dependent SV768256.DLL. I am using MASM 6.00B and made the changes exactly as stated in one of the questions (dated: 4-5-93, General OS2 and hardware) in QUESTION.ZIP.  Although the compilation and linking produces the final SV256768.DLL, the following compile and link warning messages are generated.  Should I be concerned about these?

warning L4008: aliased fix-up to non-alias object near 90 in object _PtrCode32 target external 'pointer_off'

L4038: Program has no starting address.

1) The customer himself discovered that these values are set by kernel routines. He wrote a routine to check for his chip set and adapter type; if not found, then the kernel routine is called.
 * ANSWERS:

2) OEMHELP$ is documented in the file oemhelp$.zip available for download on the BBS.

3) The compile warnings mean that 16 to 32 bit resolution is being attempted by the compiler. We have these warnings quite often, but we know what the compiler is doing and it is acceptable. The linker warning is normal because this is a DLL you are linking, not a program.

June 28, 1993 - M0006

Is there a known conflict between the 2.0 VGA drivers and port address 2E8? I am trying to get COM2 to work at this address and IRQ 15. I am getting IRQ not available from the COM.SYS driver at boot.
 * QUESTION: (Ref: 253)

However, we have a different version of COM.SYS: 8-10-92 11:06a     25064           0  COM.SYS that works for us Is this version supported by IBM?

If not, is there a version of this driver which has the fix that is supported?


 * ANSWER:The 8-10-92 version was a beta of a com.sys with fixes for the original. Since it is a beta, it is not supported. However, the Service Pak version of com.sys (dated 10-16-92, size 24,984 bytes) also contains these fixes and is supported by IBM.

June 28, 1993 - M0005

We've noticed a difference between the March '93 2.1 Beta and the December '92 Beta regarding the profile management routines. In fact, our display driver crashes with the March beta and works fine with the December.
 * QUESTION: (Ref: 251)

Specifically, our code looks like... if((hini = PrfOpenProfile(hab, "\\os2\\pmia.ini"))!=0) // hini = 4c690000 march // hini = 3 december {     PrfWriteProfileString(hini, "Hello", "There", "testing") ; // returns 1 PrfCloseProfile(hini) ;  // crashes here with March '93 beta } The error looks like ... Trap 13 (0DH) - General Protection Fault d01c, LDT eax=eab00036 ebx=00000000 ecx=00000010 edx=00000006 esi=175961e8 edi=175961e8 eip=00000470 esp=00063d56 ebp=00063dbc iopl=2 rf -- -- nv up ei pl nz na pe nc cs=d02e ss=0036 ds=0053 es=0053 fs=150b gs=0000 cr2=1a024ed6  cr3=001cf000 d02e:00000470 9a2c031fd0    call    CODE16_GROUP:DOSCOPY (d01f:032c) ##

##ln

d02e:00000140 doscall1:CONFORM16:_memsetfc + 330 d02e:00000628 _DOS32IMONREAD - 1b8 ##

What's different between the two betas regarding these Prf... routines/libraries? Why are we getting this crash?

A hint is that if we do just an open and a close with no writestring it doesn't crash. Another hint is that if we just comment out the PrfCloseProfile(hini) call, everything works fine.


 * ANSWER:There are at least three defects that I know of against the March Beta for PrfQueryProfile* calls. The problem is not with this customer's code, but in the profile functions themselves. The development group is working on fixing these problems, and I believe that they will have them fixed in the 2.1 release. There are no current builds which have this problem corrected as of Friday, April 30, 1993.h

June 28, 1993 - M0003


 * QUESTIONS: (Ref 243)

1) Are 16 bit display drivers supported by OS/2 2.0 + SPAK and will they be supported by OS/2 2.1?

2) After the installation of the Service PAK with 8514 as primary display adapter and VGA as secondary display adapter, should I be able to over write the installed IBM 8514 display driver with our 16-bit display driver for our 8514 based accelerated graphics adapter? If yes, then which file should I copy my display driver over, IBM8514.DLL or DISPLAY.DLL? What are their functions - I heard that the function of display.dll may or may have changed?

3) I have the OS/2 2.1 DAK. Since I was told that my 16 bit graphics DD wouldn't work with OS/2 2.0 + SPAK or OS/2 2.1, I assumed that maybe the 8514 display driver for OS/2 2.1 would work on OS/2 2.0 + SPAK. I rebuilt IBM8514.DLL from your sources and tried it with OS/2 2.0 + SPAK and the system hung up.  Should it have worked or did I miss an installation procedure?  If I need to redo my OS/2 2.0 Display driver, I'm hoping that I can use your 8514 sources for OS/2 2.1 to develop a display driver for OS/2 2.0 + SPAK and OS/2 2.1 at the same time.

1) Yes, they are supported.
 * ANSWERS:

2) Write over the 8514 DLL file. The DISPLAY.DLL file is no longer used in SPAK and higher (even though it is still there) by the base operating system.

3) Yes, you probably need to update your driver. The new DDK (available May 25) will have the 32-bit 8514 driver source as an example.

May 3, 1993 - G0027


 * QUESTIONS: (Ref: 213)

1. DRIVER EXECUTION

The folloing printout is produced by loading the debug versions of both IBMVGA32 and IBMDEV32 with a KDB.INI file containing the commands VSF * and G.. . Trap 14 (0EH) - Page Fault 0000, Not Present, Read Access, Supervisor eax=ffffffff ebx=00000001 ecx=00000000 edx=15160030 esi=1ac4aa76 edi=00063fd0 eip=0000000c esp=00063fd8 ebp=0003f724 iopl=2 rf -- -- nv up ei pl nz na pe nc cs=005a ss=004a ds=0053 es=0053 fs=150b gs=0000 cr2=0000000c  cr3=001c9000 005a:0000000c               Invalid linear address ##ln No symbols found ##.k Invalid linear address: 005a:0000000c ##

If I load the retail versions of the VGA driver without the VSF * and G        commands given to the debugger the output from the debugger looks like this: .        .         The system detected an internal processing error at location ##0170:fff5faf0 - 000f:0001eaf0. line 717, in file 4053 @(#)vminfo.c  6.5 91/11/05 038600d1 - 03/26 10:59:12.25 Internal revision 6.479, 92/12/09 The system is stopped. Record the location number of the error and contact your service representative.

eax=000001e7 ebx=7cf17e58 ecx=00000000 edx=00000fff esi=7d108a58 edi=00000000 eip=fff5faf0 esp=00006604 ebp=00006624 iopl=2 -- -- -- nv up ei pl nz na pe nc cs=0170 ss=0030 ds=0168 es=0168 fs=0000 gs=0000 cr2=14f11028  cr3=001c9000 0170:fff5faf0 8b4310        mov    eax,dword ptr [ebx+10] ds:7cf17e68=7cf17e6c ##g

GRE InstallMonitors : No Monitors in INI File IFI: Making a new font GRE: Recording Error: PM = 207B DOS =   0 GRE: Recording Error: PM = 207B DOS =   0 Symbols linked (pmmle) GRE Initializing Process # 00000004 GRE: Entering init routine on new process Create a loaded public or private engine font instance Create a loaded public or private engine font instance GRE Initializing Process # 00000005 GRE: Entering init routine on new process

By ignoring the previous error and continuing the driver appears to        work normally.

2. DOCUMENTATION

The display driver is apparently using routines in libraries under \DDK\LIB Where are these functions documented?

By looking at assembly .COD files, I see functions such as VIO16SETMODE. Where are these functions documented?

(Editor's notes to development - I believe that the the specific function(s) VIO16SETxxxx were documented in V1.3 and then intentionally dropped in V2.0. Is there any current documentation on the VIO16SETxxxx function(s)? How about the other functions buried in the \DDK\LIB\ files?)

Question 1) Currently OS/2 development is using MASM 6.0 for assembly and test. You indicated that you are using 6.0B. This is the most likely cause of your errors, especially since you indicate that the compiled driver appears to work if the errors are ignored. Development is looking into getting a copy of 6.0B, in the future, to verify this type of question.
 * ANSWERS:

Question 2) The only documentation that I can find is the old stuff that you (the editor) mention. The documentation on the other functions is scattered throughout many places. The primary locations for this documentation is the PDK (now the Developer's Connection) and the new DDK books to be available in May.

May 3, 1993 - G0026


 * QUESTION: (Ref: 208)

NEW BACKGROUND MIXMODES FOR BITBLT

Is there a way to disable this feature? - in DEV_CAPS? _ call back to graphics engine?

ANSWER:

In DevQueryCaps call, there is capability of the background mode support, called CAPS_BACKGROUND_MIX_SUPPORT. Display driver can return the sum of the values appropriate to the mixes supported. ( For detail please refer to PM Programming Reference Volume 1, DevQueryCaps call.) Actually the customer has good sample codes. .\SRC\VGA32\IBMDEV32\DATADEV.ASM .\SRC\VGA32\SVGA256\DATADEV.ASM When they look the above codes, they will find out that VGA32 display driver does not support new background mixmode by not setting these new values, and SVGA 256 display driver supports them by setting these values, like CAPS_BM_ SRCTRANSPARENT or CAPS_BM_DESTTRANSPARENT. So they can avoid supporting new background mixmore not setting these values in CAPS_BACKGROUND_MIX_SUPPORT.

April 5, 1993 - G0025 QUESTIONS: (Ref: 154) In our display driver (1664 x 1200, 2bpp) I have two problems with bitmaps:

1. Scheme Palette pointer: If I tell GE that my driver handles 2bpp device (shl  adDevCapsData[CAPS_COLOR_BITCOUNT * SIZE_DWORD], 1) in function device_specific_init, the color pointer in Scheme Palette Application does not change to the selected Scheme icon, it stays black arrow while other desktop icons (eg. Master Help Index) are drawn correctly. On the other hand, if I tell GE that my driver handles 4bpp device, Scheme Palette pointer changes correctly to the selected Scheme icon, but now desktop icons are drawn incorrectly (icon portions are blanked out). My driver is  2bpp, how can I resolve this problem ?

2. Min/Max and Scroll bar buttons bitmaps: Min/Max buttons are not drawn to their full size. As a result there is no  border line between them. I see the same problem with Scroll bar button bitmap. It looks like the Bitblt function is always passed a parameter "Count" with value 3 meaning, copy rectangles of the same size. How can I  tell PMWIN to stretch bitmaps ?

ANSWERS: 1. These bitmap files are in the display driver's resource directory. Display Driver developper has resposibility to prepare the bitmap files which will fit with their resolution and color capability. The sample code IBM supply is VGA and 8514 display driver, and it is very different from 1664 x 1200. We would like you to make sure that the customer has modified bitmap files to the appropriate size. To modified these bitmap files, they can use Icon Editor. ( Cut and Stretch Paste functions )

2. Assumption: I use VGA 16 bits driver. But I set 2bpp in  CAPS_COLOR_BITCOUNT and 4 colors in CAPS_COLORS to make the same environment. I could reproduce the same problem as customor's.

First I will tell you how Scheme Palette draws mouse pointer.

WinLoadPointer

WinQueryPointerInfo

DevOpenDC GpiCreatePS GpiSetBitmap

WinFillRect

GpiCreateLogColortable GpiSetBitmap

DrawSchemePreview ( internal sub-routine)

GpiAssociate GpiDestroyPS

WinSetPointer

They just loades PostIticon, and they use this pointer handle for the scheme pointer. They replace bitmap handle in pointer information from postit icon to scheme pointer bitmap.

In my case, during WinSetPointer for this scheme pointer, SetColorCursor (CURSORS.ASM) in DISPLAY.DLL returned error. The reason is that SetColorCursor check SD_COLOR bit in color bitmap. This bit is set during WinLoadPointer, actually DeviceCreateBitmap in DISPLAY.DLL. If Display driver returns 2bpp, OS/2 system bitmaps are all monochrome bitmap, not 16 colors, not 256 colors. The bitmap of Postit icon which is loaded to make for scheme pointer is also monochrome. It means that DeviceCreateBitmap does not set SD_COLOR bit. SetColorCursor check SD_COLOR bit, and if it  is not set, it returns error.

The customer can not change OS/2 system resource. The things they can do  is

- modify SetColorCursor

or

- If they are sure that they do not support color cursor, they can use SetColorCursor in GRE by changing dispatch table. (DISPATCH.ASM), because GRE's SetColorCursor just calls SetCursor, and color bit will not checked.

I hope the customer's display behavior is the same as VGA.

October 26, 1993 - P0001 QUESTION: (Ref: 178) I'm talking with a graphics board maker about OS/2 support for, among other things, their TI 34020 boards.

The main question before us is whether the TI drivers already exist in some form, and if so, who owns them. If you can provide me with any information about the TI drivers, I'd really appreciate it.

ANSWER: (update to March 19, 1993 original) To date, the only TI device driver that we are aware of is the TIGA PM driver that is available from Atlantic Research Corporation. This is a driver for TIGA and Presentation Manager on OS/2 versions 1.2 through 2.1. This driver specifically supports the #9GXi Graphix coprocessor offered by the Number Nine Computer Corporation.

For technical information regarding this driver, contact Rick Curry at (805) 484-9770. For purchasing information, contact Mike Watson at (301) 258-5557.

March 18, 1993 - C0022

QUESTION: (Ref 160)

Recently we developed a SEAMLESS driver for Windows to couple to PM driver 1024x768 16 colors for our board. Now we want to integrate it in OS/2 for testing. To build such SEAMLESS driver we used the source of a Windows 3.0 driver 1024x768 16 colors integrated with IBM modified files belonging to a DDK for Graphic Engine 16 bit (in the directory DISPLAY).

1) Is it necessary to modify the system setup for this new driver?

2) Is it needed to replace this driver with the one present in the directory   OS2/MDOS/WINOS2/SYSTEM/VGA.DRV with any other change?

3) What is (in the same directory) WINVGA.DRV?

ANSWER:

1) Yes, You need to modify OS2\MDOS\WINOS2\SYSTEM.INI for the new drivers.

2) No.

3) WINVGA.DRV is the seamless driver and you need to replace it.

March 10, 1993 - C0020

QUESTION: (Ref 131) Re: Workplace Shell's interpretation of Screen Resolution vs.  Color Depth

I've been working on implementing a 4BPP 1024x768 PM driver as a follow-on to two 8BPP PM drivers, one at 1024x768 and the other at 800x600.

I have run into the following anomaly in the behavior of the Workplace Shell:

It appears that WPS maintains 2 sets of icons/bitmaps for common shell objects (e.g., Templates Folder, Master Help Index, Start Here, etc.). One of these was evidently intended for XGA/8514A support and the other for VGA.

The bitmaps for the high resolution set differ from the VGA in _BOTH_ scale and color handling. The XGA/8514A icons are larger than the VGA (i.e., more pixels per scan), and in rendering backgrounds they employ pure colors where the VGA employs dithered colors. Thus, for example, the common light yellow color used in the background of objects such as folders, the system clock, etc., is a pure color in the high resolution icons but a yellow-and-white dither in the VGA icons. The pure color, moreover, is NOT one of the standard 16 system colors; it is available only on displays using 256 colors or more.

This scheme has posed problems for us in implementing a 4BPP 1024x768 PM driver. WPS decides which set of icons to use based on the resolution of the PM driver. Drivers for 1024x768 or greater get the XGA set; those for lower resolutions get the VGA set. Thus our 1024x768 4BPP driver gets the 256-color icons/bitmaps, whose non-standard colors it must convert to the nearest standard color. The result is a Workplace shell which, using the standard PM color conversion algorithm, is largely monochrome. The non-standard light yellow comes out white. The non-standard dark cyan used in the Start Here target icon comes out gray.

What we need in the WPS bitmaps and icons is either a single color scheme using only the common 16 system colors, or FOUR sets to handle independently the varibles of resolution and color depth.

In the absence of such a solution, have you any suggestion about how to handle the color-conversion problems posed by WPS's use of non-system colors in the high-res icons?

ANSWER:

The XGA driver has also the same kind of problem when memory is not enough and XGA choose 16 colors. In this case Templates icon shows white ( Refer to the attached note. ) And also there is another driver called ATLAS 16 color driver, it is also 1024 x 768. It also shows Template icon white after mapping 256 to 16. I talked to PMWIN, white, not gray after mapping from 256 to 16. I talked to PMWIN, WPS resource person it looks like restriction right now. The follow is from a note generated by development:

The famous white icons problem,

After further investigation, it has been found that the white icon problem is not a bug.

When the XGA adapter has only 1/2 Mb of VRAM, 256 colors cannot be achieved at a resolution of 1024x768. Under this condition 16 colors are used.

On the above system, the 8514 icon format is the one chosen by the operating system. The 8514 icon format expects 256 colors and does not use dithering. The yellow used is a very pale yellow which is not available in the physical device palette when using 16 colors. The pale yellow in the icon will be nearest fit to white when the icon is drawn to the screen.

This problem will not be seen on VGA systems running with 16 colors because the icon format chosen will be the pre-dithered VGA 16 color format.

The VGA format cannot be used on the XGA system running in high res because of the physical dimension differences. The VGA icon format is 32x32 and the 8514 icon format is 40x40.

One possible, (but not practical) fix to this problem is to enhance the icon editor to support another device format. This icon format would use a 40x40 grid and only 16 colors. This would effect every icon in the system. All icons would grow in size because of this.

The system object has been enhanced to allow the user to switch resolutions. If the user is color conscience, they can always switch to 640x480x256 colors using the system object screen resolution page. This mode is supported with 1/2MB of VRAM.

January 4, 1993 - G0007 PROBLEM/QUESTION (Ref: 085) Two simple questions about your applications running under my 24 bit colour display driver.

1. Solitaire-Klondike Sends my driver 4 bit colour bitmaps for conversion but sends 8 bit colour bitmaps to a standard 8 bit display driver.

My problem or yours? If mine, in what Query call or DEVCAPS selection have I erred.

2. PM Chart The Color/Style etc.. selections show as Grey Scale in the Dialog Box even though the selections function as the true colour.

My problem or yours? If mine, where have I strayed.

1. Solitare - Klondike The solitare code uses the DevQueryCaps (CAPS_COLOR) API to        determine which bitmap resources to load. It loads the 8 bit resources if the number returned is greater than or equal to 256. Check your return to the function.
 * ANSWER

2. PM Chart IBM does not have or own the code for PM Chart. It is a MicroGrafx product which they give us (in binary) to ship with the product, so we are not able to comment on your problem.

January 4, 1993 - G0005 PROBLEM/QUESTION (Ref: 075) I am trying to create an SVGA display driver install disk. Using a .DDP file (for "Device Driver Install") will not perform the necessary changes to CONFIG.SYS and I have been unable to find documentation of .DSC files for DSPINSTL.EXE.

- OR -

Currently we are installing our display driver manually by copying it to a TEMP directory, then changing the LIBPATH in CONFIG.SYS and then rebooting. Is there a way to do the whole procedure automatically using some script and Sellective Install or Device Driver install?

ANSWER Documentation describing Display Driver Installation and Configuration will be included in the DDK (CD-ROM media) targeted for release Jan '93. .DSC file documentation is included. If a copy of the pre-release document is needed prior to the CD-ROM version, it can be mailed to you. Please call 407-982-6802 or 407-443-1519.

November 10, 1992 - BK05001B


 * PROBLEM/QUESTION:Is it true that the original OS/2 2.0 supports only 16-bit device drivers?


 * RESOLUTION:This is true. The 2.00 release has a 16 bit graphics engine that only supports 16 bit drivers.

November 10, 1992 - BK05001B


 * PROBLEM/QUESTION:Is it true that the updated OS/2 in ServPak supports BOTH 16 and 32-bit display device drivers? How does the kernel/engine know if it's talking to a 16 or 32-bit driver?


 * RESOLUTION:This is also true. The engine knows which one to load by an entry in the OS2SYS.INI file.  We will be shipping a utility called DSPINSTL with our DAK that you will be able to ship with your product that will install your driver and make the correct entry in the .INI file for you. It just needs to be configured for your particular driver.

November 10, 1992 - BK05001B PROBLEM/QUESTION

Is it true that 16-bit drivers receive pascal calls and 32-bit 'C' calls?

RESOLUTION

Yes

November 10, 1992                                                     BK05001D PROBLEM/QUESTION

Can we use our Windows display driver in a WINOS2 session while using the default vga driver in the PM session? If so, what are the steps necessary to install it (system.ini etc)?

RESOLUTION

Yes, you should be able to use your windows driver in a WINOS2 session. It   is suggested that you look at the discussion of the SVGA ON utility in the README file supplied with OS/2 in the root directory of the boot drive. It sets up the virtual device driver for SVGA and allows you to   use SVGA in the DOS VDM.

Small Computer System Interface
June 28, 1993 - M0009


 * QUESTION: (Ref: 266)

I am writting a SCSI ADD.

If I get a UNIT ATTENTION with ASC=0x29, should I retry?

Should I set IOERR_DEVICE_RESET?

Also, the section "Error Handling" says that IOERR_RETRY is a flag that tells the ADD to retry if an error occurs. Section "Summary of Error Codes" shows some items as "retry required". But, section "I/O Request Block - C Definitions" does not have IOERR_RETRY set for some items that section "Summary of Error Codes" shows to be "retry required". The items in question are the following: IOERR_ADAPTER_NONSPECIFIC IOERR_DEVICE_RESET IOERR_DEVICE_NONSPECIFIC

Which part of the document is correct?

In general when the IORB_DISABLE_RETRY is NOT set in an IORB then the ADD should retry a command which produces a Check Condition.
 * ANSWER:

There is the following exception to this policy for removable media devices:
 * A significant event would be masked by a retry:
 * Device Not Ready
 * Ready To Not Ready To Ready Transition (Media Changed)
 * Device Reset

Special considerations for error handling on removable media devices are discussed in the Q & A section of the spec.

The RETRY_REQUIRED flag in the error codes is intended as 'advice' as to whether a retry is likely to be productive.

In some cases the nature of the error leads to the conclusion it will not be corrected by a retry.

The ADD implementer may test this flag to determine whether to proceed with a retry or ignore the flag provided the considerations in Item 1 are met.

One thing to keep in mind when designing error recovery code in the ADD, is that once the error is reported out of the ADD driver, it is considered non-recoverable. In general Device Managers that implement their own error recovery logic will set the IORB_DISABLE_RETRY bit so they can manage error recovery themselves. If this bit is not set then the ADD writer should assume that if an error is reported, it will result in an error pop-up on the user's screen.

June 28, 1993 - M0004


 * QUESTIONS: (Ref: 250)

1) A device to which we were sending data in Synchronous mode rejected the Extended Message (hex 01). This Extended Message was issued to the device after the device returned a Check Condition status, and at which time the device was to be queried for sense data. The device responded to the Extended Message with a Message Reject message (hex 07).

The solution provided by Boca was to specify Asynchronous mode operation to that device. To do this, the developers in your department instructed us to add the /A:x /!SN:y flags to the IBM2SCSI.ADD statement in the config.sys file, thereby making data transfer Async between adapter "x" and device "y". This in theory was to inhibit the IBM2SCSI device driver from sending Extended Message.

As it turned out, it didn't, and you sent us a new IBM2SCSI.ADD. How will the private fix which you sent to us be delivered to the field? Is this fix in the 2.1 code? Is there an APAR to which the customer can get the fix for his 2.0 system?

2) In relation to the problem described above, what is the association of Synchronous Mode/Extended Message?
 * a) if a device supports Synchronous, is it supposed to support Extended Message? Is this in the ANSI standard?
 * b) in our case, was the scanner device to which were were communicating correctly or incorrectly implemented?

3) The parameters /Ax /!SN:y on the IBM2SCSI.ADD statement are not documented in the OS/2 2.1 online information (at least not in the 6.498 Beta version).
 * Are these parameters documented anywhere? Will we be forced to document this with our product?  Are you committed to holding this definition constant in future releases?

4) The parameters described above would seem to have the same implications with other SCSI hardware (such as Adaptec, Future Domain, etc.). Are these parameters supported on other .ADD driver invocations in the same fashion? In the SCSI.INF, the online version of the spec for OEM SCSI device drivers on the DDK, it specifies that the /DM and /SM parameters are mandatory, but support for the remaining parameters (like /SN) "is optional". Consequently,without getting one of each of these adapters and trying it out, I can't tell
 * a) whether it can be made to work
 * b) whether we have to specify different setup methods with each adapter.

I don't know how to resolve this point. Does your group not know what is supported by each vendor (Adaptec, Future Domain, ...)?


 * ANSWERS:

1) According to development, the fix sent to you is included in OS/2 2.1. It should be in all builds after v6.509. There is no APAR written against OS/2 2.0 on this problem.

2) Normally a device that supports the synchronous SCSI transfer protocol will support the extended SCSI message (Synchronous Data Transfer Request) at any time it is sent by the adapter. For PS/2 SCSI adapters, we normally send this message along with the first command to the device after power-on (which is usually an Inquiry command issued by the SCSI BIOS POST). We will also send this message again if the adapter is reset or if the device returns check condition status which may be caused if the device has been reset. A device reset causes it to default back to async transfer mode. There is a special bit (NS) in the SCB command blocks that are sent to the adapter by the device drivers that will prevent the adapter from sending the extended messages for that command with the NS bit set to 1. This bit is not normally needed because the adapter is smart enough to remember if it ever tried to send the extended message and failed, then it won't ever try to send it again to that device unless the adapter is reset again. So we don't recommend using the NS bit.

If the device truly supports sync transfers then it should be capable of accepting the extended messages at any time. If this device is not following this rule, then it is not complying with the SCSI standard.

3) The IBM2SCSI.ADD parameters are documented in the file SCSI.INF included with the DDK. This documentation is in the following section: If your product requires these parameters in config.sys in order to operate successfully, then you will need to document this for your customers.
 * SCSI.INF
 * ADD Command Line Parameters
 * Syntax Conventions
 * SCSI-Specific Parameters

4) In our group we provide OS/2 device driver developers with technical support, but we have no way of tracking what all those vendors are doing. So we have no way of providing you with information as to what parameters are supported on various adapters by various vendors. We can only suggest that you contact the vendors as necessary.

April 5, 1993 - G0023

We are developing an ADD SCSI driver for OS/2 2.0.
 * QUESTION: (Ref: 204)

The driver reads and writes directly to the SCSI controllers through the use of memory residing on the SCSI controllers. The shared memory addresses reside at memory locations above 64 MB and reside in different segments.

The driver requires a separate GDT for each SCSI Controller. It is possible for a system to contain 8 controllers. Thus, the driver needs 8 GDTs. The driver also requires another GDT for a fixed memory area in system memory used for to pass data to the SCSI controllers. This is a total of 9 GDT's required.

Are there any limitations on the number of GDTs which a driver may or should reserve for its own use?

GDT is Global Descriptor Table which is selectors array.
 * ANSWER:

Usually, at initialize, PDD saves some selectors for accessing the physical address using DevHlp_AllocGDTSelector. And later when PDD actually accesses, it uses DevHlp_PhysToGDTSelector to convert 32-bits address to a GDT selector-offset pair. When PDD does not need GDT any more, they can just call DevHlp_FreeGDTSelector.

In DeHlp_AllocGDTSelector, there is a parameter to specify how many selectors the caller wants. In this case the customer can set to "9". It should not be a problem.

March 17, 1993 - C0021

optical controllers and optical drives. The controller uses one SCSI address and each drive uses a Logical Unit Number (LUN) at the SCSI address of the controller. The problem seems to be that OS/2 only supports SCSI addresses at LUN 0.
 * QUESTION:I am writing an OS/2 2.0 driver for SONY optical drives. SONY has seperate

ANSWER:It is true, OS/2 2.0 does only support SCSI addresses at LUN 0. But wait, there is more! Support has been defined and supported in OS/2 2.1. Under 2.1 the /ET switch was added to most of the SCSI base device drivers, which signals that non-LUN 0 addresses are to be supported. The switches are documented in the current 2.1 Betas under the BASEDEV= section of the Online Command Ref. The Adaptec drivers (in the same build) should correctly implement these switches.

March 16, 1993 - G0019


 * QUESTION: (Ref: 176)

Subject: URGENT SCSI.SYS QUESTION

Hi! I have a couple of questions to which I urgently need answers. I am writing a SCSI decice driver for a scanner and have the following lines in my config.sys: BASEDEV=IBM2SCSI.ADD /LED BASEDEV=OS2SCSI.DMD I am communicating with the scanner through a MicroChannel SCSI adapter card. Now, when the device returns a 'check condition' status the GDD automatically sends an 'Identify' message (hex C0) followed by an 'Extended Message' (hex 01). The device responds with a 'Message Reject' message (hex 07). I have found that the adapter card tends to send out the 'Extended Message' when its NS (no synchronous) bit is not enabled.

Consequently, I have enabled NS in my device driver code when I do TransferSCB calls to the Adapter card, and I need some way of getting the GDD to do the same during error handling.

My questions are:
 * 1) How can I do this?
 * 2) What does the /LED flag in my config.sys do?  I have been searching for these answers in the documentation I have relating to the GDD, alas to no avail, which begs the question:
 * 3) Are the answers to these questions documented and available?


 * ANSWERS:The reference to GDD (General Device Driver) comes from your being involved with OS/2 v1.3. You are using the Generic SCSI Input/Output OS/2 Device Driver Workbook. You also referenced the SCSI.SYS file in your note. The SCSI.SYS is broken into the two files IBM2SCSI.ADD & OS2SCSI.DMD in OS/2 v2.0.
 * 1) Change BASEDEV=IBM2SCSI.ADD /LED to BASEDEV=IBM2SCSI /LED /A:your adapter address /!SN:your target ID.
 * 2) The /LED allows the LED on your adapter to be turned on.
 * 3) Answer #1 is documented in the OEM DASD And SCSI Device Driver Support document available on the DDK.

February 02, 1993 - G0015


 * QUESTION: (Ref: 122)

Title: Which card(and firmware) does AHA174x.ADD support?

When using AHA1740 card(firmware version 1.2 11-06-90), system stop happens by the following procedure.

Copy files into same HDD from 2 different sessions infinitely.

But when using AHA1740A, this problem does not happen.

(1) Does AHA174x.ADD support AHA1740 SCSI card?

(2) If yes, is there any restriction about firmware version of AHA1740, such as firmware version must be 1.3 or later.


 * ANSWER:Although Adaptec did not specifically address the question of restrictions to firmware level 1.2, they did say AHA174x.ADD supports the AHA1740 card. The current ship level BIOS is version 1.40. The latest level of both the BIOS code and the microcode can be downloaded from Adaptec's bulletin board (BBS). The BIOS must be burned into the EPROM, but the microcode can be loaded on the fly for the 1740 only (the 1740A microcode needs to be burned into the EPROM).

A beta version of the 1740 driver is also on their BBS. Here is additional information if you are is interested. BBS - Phone number 408-945-7727 9600 baud Comm settings - N,8,1 User can register himself & assign own password

Files to download (for 1740 only): 1740BETA.ZIP - beta driver file 174XCODE.EXE - BIOS file for 1740/1740A & microcode for 1740A only ASWM174.EXE - microcode for 1740 only

To load the microcode on the fly (1740 only), use the ADL utility found on the ASWC174 diskette shipped with the Adaptec card.

January 26, 1993 - G0013

I currently have an application that talks to a device driver I wrote that talks to OS2ASPI.DMD to gain access to SCSI devices attached to a DPT SCSI Host adapter. This all works fine.
 * QUESTION: (Ref: 110)

When I try to implement Scatter/Gather, for performance reasons, I have a TRAP in the DPT device driver. I don't see what I did wrong. The DPT device driver is trying to access the logical address of the scatter/gather list (stored at offset 0x46 in the packet passed to the DPT driver). I did put the PHYSICAL Address of that list into the Data Buffer Ptr field of the ASPI packet. That address does show up at offset 0x4A in the packet passed to the DPT driver.

So the question is:
 * 1) Does OS2ASPI.DMD support scatter/gather?
 * 2) Who is responsible for creating LOGICAL address of the scatter/gather list? I assume from the ASPI specification (from Adaptec) that I should only put the Physical address of the SG list into the ASPI packet. And that the Pointers in that list of buffer address' should be the physical representation also. Where have I gone wrong?


 * ANSWER: OS2ASPI.DMD does support scatter/gather. You are correct in putting only the PHYSICAL address of the SG list into the ASPI packet. You are also correct that the pointers in the list of buffer addresses should be PHYSICAL. Your problem was caused, according to Adaptec when you talked to them, because "a line of code was missing". Adaptec sent you a new OS2ASPI.DMD and your problem was corrected.

October 15, 1992 - BJ15029

Timeout during test of ESC2ADD SCSI device driver.
 * PROBLEM/QUESTION

Monitor shows "OS2 !!000001915",

Debugging terminal shows "NWD WARNING: a filesave timeout was detected at cs:ip= 540:2b89 "(QueueIORB). I understood the message was put out due to the device driver hold off the processor interrupt for the period longer than NMI watch dog timer expect it to be. I changed the code to eliminate that, but it still trap at 170:fff507ee when the 12 concurrent processes running for about 1&1/2 hrs.

The similiar kind of driver logic was working in OS/2 1.3 LADDR architecture. (We had a working driver for the same SCSI adapter).

The NWD timeout error is because the driver is sitting in a tight loop. The ill IORB entry has the pNxtIORB point to itself. DequeueIORB routine should make sure that the IORB request control flag IORB_CHAIN bit is set before dequeuing a valid pNxtIORB entry.
 * RESOLUTION

Super Video Grapics Adapter
May 6, 1993 - M0002

I want to refer to the Question under caption: "General OS/2 and hardware questions", dated: April 5, 1993, in the file: QUESTION.ZIP. I am facing the same problem using the files: IBMVGA32.DLL and IBMDEV32.DLL in the DDK, as stated in the question.
 * QUESTION: (Ref 238)

The files were compiled with the same modifications as mentioned in the question. I got the following Link error for IBMDEV32: L4038: Program has no starting address. The MASM manual says that this error should not occur for DLLs.

Also, I used the KDB.INI file with the debugger as suggested by you. All I could trace is that the OS/2 jumps to an invalid page and thus produces a page fault. (The debugger commands "ln" and ".k" do not work because of page error.) The debugger output at the time of error is as: Trap 14 (0EH) - Page Fault 0000, Not Present, Read Access, Supervisor cs=005a ss=004a ds=0053 es=0053 fs=150b gs=0000 eip=1ad33000 esp=00063dc4 ebp=00063e7c iopl=2 Note: cs:eip point to an invalid page.

If you have any suggestion, please let us know.

I am all out of suggestions at this point. At the point where you are now, debugging the driver is an art, not a skill. I can't even begin to quess what to try without doing the debugging myself. Sorry! I would suggest putting some INT3 breakpoints into the code to stop it and see what is going on.
 * ANSWER:


 * QUESTION: I am developing 256c, multi-resolution SVGA driver for our chipset, like Tseng, Trident, etc. I am new to OS2. Can you tell me which drivers require modification for this task.


 * ANSWER:I assume you are going to be writing a 32-bit driver. If so the 32-bit SVGA drivers are:
 * BVHSVGA.DLL - base video handler - this will require modification.
 * VSVGA.SYS - virtual device driver - should not require modification, as this is hardware independent.
 * SVxxx256.DLL - Physical device driver - (xxx=resolution, yyy=#colors) will require modification.

May 3, 1993 - G0029


 * QUESTIONS: (Ref: 225)

1. GENERATION AND EXECUTION OF THE SVGA DISPLAY DRIVER

In order to extend the SVGA driver provided on the DDK for a new board I understand that some changes must also be made to the BVHSVGA.DLL physical device driver.

I have made all the changes I believe shold be needed, yet it does not work. I have trouble understanding how drivers are loaded under OS/2 and cannot say I have found this mechanism documented properly anywhere:
 * The line: SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA)
 * 1a. Why is BVHVGA loaded even if it is erased from the above line?
 * 1b. What is the definition of the parameters to DEVICE mean?
 * (I have seen examples using more than two names e.g SET VIO_SVGA=DEVICE(BVHVGA,BVHSVGA,BDBVH) )
 * After having installed our modified version of the PM SVGA display driver as well as the modified versions of the physical drivers BVHVGA and BVHSVGA a problem occur detecting the board as a supervga board. The sequence:
 * in BVHVGA.DLL:

DevEnable GetSVGAConfig VidoIoctl DosOpen DosDevIoCtl   <======== Dosclose
 * DosOpen opens somthing called OEMHLP$ and DosDevIoCtl is called with :

function = 8 category = 0x80
 * 2a. What is OEMHLP$ and where is it documented?
 * A similar sequence is found:
 * in BVHSVGA:

DevEnable GetAdapterConfig VidoIoctl DosOpen DosDevIoCtl   <======== Dosclose
 * The call DosDevIoCtl is converted internally to:

DOS16DEVIOCTL
 * 2b. Where is this conversion documented?
 * The Adaptertype parameter contained in the data area to DosDevIoCtl is updated by the above mentioned call to a 1 when using a video7 display adapter. It is returning zero when I am using the adapter I am modifying the driver for.
 * 2c. Please explain


 * ANSWERS:
 * 1a. BVHSVGA uses calls in BVHVGA. Since BVHSVGA uses BVHVGA it is loaded whenever BVHSVGA is loaded even if the chaining is not provided.
 * 1b. The drivers are chained together in this example. There may be up to 16 drivers allowed in the "parameters" to DEVICE. However, I can't think of a reason to use that many.
 * 2a. OEMHLP$ is used to identify hardware known to the OS/2 kernel. This includes only the default or base devices. This API is only useful for known hardware. The vender of the hardware must use an API or some sort of executable (exe, dll) to identify their own physical device characteristics. This would be the job of the device driver writer. The API mentioned above should operate in the same manner that OEMHLP$ does with the known hardware. The OEMHLP$ will be documented in the Physical Device Driver Reference for OS/2. It was to be included in the DDK, but because of certain details it had to be pulled. In the very near future, the sanctioned OEMHLP$ will appear on the BBS.
 * 2b. Currently, all physical devices are 16 bit. The conversion of the DosDevIoCtl to Dos16DevIoCtl represents a standard thunk. Since thunking is not really a documented feature there is no documentation on the thunk. For more information on DosDevIoCtl there is a section in the OS/2 1.3 Control Program Programming Reference manual. This will explain more about DosDevIoCtl, but it will mostly reference the diffent categories of IOCtl referenced in both the 1.3 and 2.0 Physical Device Driver Reference manuals.
 * 2c. This questions seems to be quite obvious, unless I am interpretting the question incorrectly. The reason the video7 display adapter is recognized is because it is one of the "known" physical devices referenced in the answer to question 2a. about OEMHLP$. The adapter board will not be recognized until the vender has a physical device driver that includes the API that emulates what OEMHLP does for the hardware devices currently known to OS/2. Therefore, the call will always fail and return a zero. Once the PDD is written and working this should not occur and the IOCtl will complete successfully and return a 1.

April 5, 1993 - G0021

NEW BACKGROUND MIXMODES FOR BITBLT
 * QUESTION: (Ref: 208)
 * 1) Is there a way to disable this feature?
 * 2) *in DEV_CAPS?
 * 3) *call back to graphics engine?

.\SRC\VGA32\IBMDEV32\DATADEV.ASM .\SRC\VGA32\SVGA256\DATADEV.ASM When they look at the above codes, they will find out that VGA32 display driver does not support new background mixmode by not setting these new values, and SVGA 256 display driver supports them by setting these values, like CAPS_BM_SRCTRANSPARENT or CAPS_BM_DESTTRANSPARENT. So they can avoid supporting new background mixmode by not setting these values in CAPS_BACKGROUND_MIX_SUPPORT.
 * ANSWER: In DevQueryCaps call, there is capability of the background mode support, called CAPS_BACKGROUND_MIX_SUPPORT. Display driver can return the sum of the values appropriate to the mixes supported. (For detail please refer to PM Programming Reference Volume 1, DevQueryCaps call.) Actually the customer has good sample code.

January 5, 1993 - G0008

I have a few questions regarding the SVGA DDKs. They are:
 * PROBLEM/QUESTIONS (Ref: 075)

Question 1:
 * As part of DevEnable in the early 16 bit SVDH, it makes a DosDevIOCtl call to retrieve the SVGA Hardware information.
 * A) To where is this call made? (SCREEN02.SYS?)
 * B) How would you add additional SVGA hardware to the recognized list?

Question 2:
 * The VDD and SVDH are fairly device independent by using a .PMI file. Is the 32bit display driver also flexible? (i.e. Are banking routines built into the code?) Is the display driver resolution also configurable through a config file?

All of these questions would probably would be answered if I had the DDK in hand, but I need to scope the developement effort needed to create true SVGA drivers for OS/2 2.0.

Question 1:
 * ANSWER

a) The call is made to a device driver in the OS/2 loader. Currently we support several of the top selling video cards in that driver so we can be compatible with a wide range of OEM machines.

b) We here at development would have to add any additional cards to the base SVGA support. I'm not sure what the process would be to add an additional card to the base support, but that should not inhibit you from creating a driver specifically for your card.

Question 2:

The 32 bit display driver is semi-flexible (?). Yes banking routines are built into the code but they are contained in large switch statements by the card manufacturer so that the same driver can handle multiple bank setups. Resolution is done by conditional compilation of the same source, producing different DLLs for each resolution.

October 26, 1992 - BJ06012-01


 * PROBLEM/QUESTION:How can I migrate a 1.2 device driver to 2.0?


 * RESOLUTION:We are providing instructions on exactly how to do that in the DAK that should be released later this year or early next.

October 26, 1992 - BJ06012-02


 * PROBLEM/QUESTION: We are having problems with scrolling of text and with icons not displaying colors.


 * RESOLUTION:This will be fixed in the DAK that should be released later this year or early next.

October 26, 1992 - BJ13003-03


 * PROBLEM/QUESTION:The sample code used appears to have been a pre-DDK 1.1 made available by MicroSoft.


 * RESOLUTION:The sample code is incorrect, and will be refreshed in the DAK that should be released later this year or early next.

October 26, 1992 - BJ13003-04


 * PROBLEM/QUESTION: We currently process Win-OS2 as a VGA pass-thru (much as we do full-screen OS/2 and DOS windows. This pass-through is implemented as a VGA-sized window in the center of our larger 1024x760 display. OS/2 and DOS appear to be sized correctly but the WIN-OS/2 session is clipped to the VGA window. The WIN-OS/2 desktop is bigger than the VGA screen so the desktop icons are "below" the bottom edge of the VGA window. Why does this coordinate translation occur, and why does it appear to happen to WIN-OS2 only?


 * RESOLUTION: WIN-OS2 is not intended to be run in a DOS window. You will have coordinate translation problems if you do. Running WIN-OS2 on the PM desktop should be done using the SEAMLESS methodology, in which the windows application actually shares the desktop with the PM application. All of the information on how to do this is currently being documented and will be included in the DAK that should be released later this year or early next.

October 26, 1992 - BJ13003-06


 * PROBLEM/QUESTION: We cannot assemble using the "masm" command in MicroSoft Assembler 6. Has anyone else encountered any obvious problems assembling 2.0 drivers using the 1.1 MASM, Link, etc. values for FH256?


 * RESOLUTION: Currently, for our 16 bit drivers we use MASM 5.1, and our 32-bit drivers use MASM 6.0. We do not use the FH256 drivers.

October 26, 1992 - BJ13003-08


 * PROBLEM/QUESTION:How do I send debug messages via debug kernel to serial port from my dll (replacement of DISPLAY.DLL) and from device driver (DEVICE=IOCTLDRV.SYS)?


 * RESOLUTION: From DISPLAY.DLL use the color_puts macro to output to the kernel debugger serial port. The macro is in the file SEAMLESS.INC, and an example of its use is in the file INIT.ASM.

Tape Device Drivers
November 5, 1992 - BK02001

We are supporting QIC/80 tape drives which interface to the standard floppy controller (QIC/117 spec). The problem which arises is that the ADD driver for the floppy owns the hardware (ports, irq, etc.).
 * PROBLEM/QUESTION

Although it is not a requirement that the tape and the floppy be in use "simultaniously", Is there any way short of changing config.sys and rebooting, to allow the tape driver access to the controller?

The following private interface (soon to be published) to share IRQ6 between the OS/2 floppy DD (ibm?flpy.add) and any other device drivers or application programs. This interface is present on OS/2 1.2, 1.3 & 2.0(GA) and the only restriction is that the floppy drives are inactive until the tape device driver returns ownership of the floppy controller to the ADD. IO requests to the floppy drive are queued until they can be serviced.
 * RESOLUTION

The solution is for the tape device driver to issue the private interface with a value of 1 (Exclusive ownership is requested), do its thing, then issue the private interface with a value of 0 (Exclusive ownership is returned). Category 8 - Logical Disk IOCTLs

Function 5DH - Diskette Control

This function is used to coordinate exclusive ownership of the diskette controller.

Parameter Packet Format

Field                   Length Command Information      BYTE

Indicates whether application is requesting or returning exclusive ownership of the diskette controller.

VALUE        Description 0       Exclusive ownership is returned to                                         the OS/2 disk device driver.

1       Exclusive ownership is requested from the OS/2 disk device driver.

Data Packet Format

Field                   Length Reserved. Set to 0       BYTE

October 19, 1992 - BJ19001


 * QUESTION: Is there or will there be a tape device driver in OS/2?


 * ANSWER: There are plans for this support in the future.

Mouse and Pointer Devices
May 3, 1993 - G0030


 * QUESTIONS: (Ref: 237)

1) Why does the VMSE need to know what type of mouse is installed and which port & irq the mouse uses?

2) What does the device dependent mouse driver need to provide to satisfy the virtual mouse driver?

1) In order to pick an IRQ that is guaranteed not to conflict with any other virtual device driver, the DOS session queries the mouse device driver at initialization for its physical IRQ. It is not important to have the real mouse IRQ, but simply an IRQ that no other VDD needs. Same as the type of mouse and port uses. They don't have the real operation in VMOUSE, but the information are there for DOS apps to query.
 * ANSWERS:

2) The IDC provided by the device-dependent device driver must support the following requests:
 * Query_Config
 * Read_Enable
 * Read_Disable
 * Disable_Device
 * Enable_Device

Refer to "Input/Output Device Driver Reference" for more detail info. The INF file, S71G1898.INF, of previous book also available in DDK #2.

March 29, 1993 - C0024

I have written a serial mouse driver. I attach the IRQ at initialization time and keep it. When the COM driver is loaded after the mouse driver, I get an error message "COM1 did not install. Interrupt level is not available.". When I load the IBM mouse driver that comes with the OS/2 2.0 release and then load the COM driver after it, I do not get this error.
 * QUESTION: (Ref #116)

1) Is this because the IBM driver sets and unsets the IRQ at initialization time just to see if the IRQ is available but doesn't actually set the IRQ and keep it until a later time?

2) When does the IBM standard mouse driver set the IRQ?

3) Does the IBM driver support the DEVICE OPEN packet?

4) If I set the IRQ at during Read_Enable or Enable_Device request processing, would it prevent this error?

1) No.
 * ANSWER:

2) At driver init time.

3) No.

4) No.

Three issues to think about:

1) When hooking the IRQ line are you signaling "Shared", this is especially important on EISA and MCA busses.

2) During init time of the IBM mouse driver, it goes into the 40: data area of the system Bios area, finds the pointer device, and zeros out the 40: data area. This signals to the com driver that this port was taken.

3) Placement is always important in config.sys.

February 16, 1993 - C0017


 * QUESTION: Where are the sample programs DEMODB.ASM (A character device driver) and MONITOR.ASM (A character device monitor) that on page 6-33 of the Physical Device Driver Reference are said to be in the OS/2 2.0 toolkit? They can't be found anywhere.


 * ANSWER: Oops, they were 1.X sample programs and obviously are no longer toolkit samples for 2.0. Unfortunately the reference to them was not removed from the Physical Device Driver Ref. These samples have been replaced with a sample PDD in the toolkit and by the samples on the DDK.


 * QUESTION: (Ref 020)
 * The mouse device driver section on OS/2 1.3 was divided into a device dependent section and a device independent section. A user could install the mouse driver and then install their device dependent code over the mouse driver's, leaving their dependent code connected to the

mouse independent driver and have the mouse dependent code hanging off their code. For example... DEVICE=C:\OS2\MSSER01.SYS SERIAL=COM1 (The device dependent code for the mouse is in a separate device driver.) DEVICE=C:\USERTOU.SYS SERIAL=COM2 DEVICE=C:\OS2\MOUSE.SYS TYPE=MTOUCH$ The problem is that OS/2 2.0 rolled the mouse driver code all into one making it impossible for them to connect in like before. The dependent drivers such as MSSER01 are no longer available as seperate device dependent drivers, instead MOUSE.SYS chooses enternally which dependent driver to install. Ther problem is when the TYPE= field is now used on MOUSE.SYS it sees no reason or need to install the normal mouse dependent code. What should a mouse device driver do?

1) There is an undocumented keyword STYPE= which is allowed on the MOUSE.SYS statement. When this keyword is used in replacement to the TYPE= keyword then the specified driver is loaded AND the default driver is still loaded.
 * ANSWER:

2) The PenPM architecture will provide generic support for such arrangements in the future. Future releases of the DDK will contain PenPM driver samples.

3) The 1.X mouse dependent drivers will be present in OS/2 2.1.

January 27, 1993 - C0013


 * QUESTION: (Ref 059)
 * We need technical information on exactly how the mouse driver works in both OS/2 1.3 and 2.0. Our main concern is how the mouse acceleration can be controlled and shut off.  With any mouse there is some mouse acceleration algorithim that controls how my mouse tracks across the screen.

We need a 1 to 1 pixel move for the mouse, meaning, as I move my mouse across the screen it moves 1 pixel at a time (VGA mode). In MS Windows there is a control panel that allows you to unaccelerate your mouse tracking It is vital to our product we have an unaccellerated mouse. It will not work any other way.


 * ANSWER:
 * An undocumented IOCtl exists in 2.0 for controlling the mouse acceleration. If the program NOACCEL.EXE posted on this BBS is ran in a PM OS/2 window, it will shut off the mouse acceleration. No such abilitiy exists in OS/2 1.X so it is not possible to shut off mouse acceleration there.

January 15, 1993 - C0011
 * QUESTIONS:
 * Having trouble writing my mouse driver using the information given in the PDD reference.


 * ANSWER:
 * Did you know about the following corrects to the PDD reference manual?

1) Page 12-3: The sentence that starts at the bottom of this page and continues onto the next page should be crossed out, it is not true. Refering also to page 18-138, Process_Absolute will only set bits 1 and 2 of event mask data packet.

2) Page 12-6: The Config_Data structure presented on this page is show incorrectly. The actual structure is 9 bytes long and has another field at the bottow of the structure, just after Com_Num. The field is as follows... Com_Port  dw   ? ; Com port address.


 * QUESTION: With my mouse driver installed, the mouse cursor disappear at some point during OS/2 startup and never comes back.


 * ANSWER: Make sure that you select a proper mouse_type in the Query_Config request (see PDD ref page 12-6). A mouse_type of 0 (Unknown) will cause this type of behavior.

General OS/2 and hardware questions
April 5, 1993 - G0024

QUESTIONS: (Ref: 196)

1. MASM 6.0

During our last conversation I got the understaning that we should really have MASM v6.0, the same assembler as IBM is using and no other variations of the assembler. I agree, and have been in contact with both Microsoft sales and Microsoft product support. They can inform me that they do not provide MASM v6.0 to customers anymore.

Does IBM have any suggestion to where a copy of MASM 6.0 may be available?

- 2. DRIVER GENERATION

In the meantime I have tried to build and install the standard 32 bit version of the display driver (IBMDEV32.DLL and IBMVGA32.DLL). The display driver has now "successfully" been assembled with MASM 6.0b after the following changes:

DDK\SRC\VGA32\IBMVGA32\SCANLINE.ASM ; Changed as the assembler does not accept. Line 2304

;and    ebx,ega_inner_stosb-ega_first_last

push   eax mov    eax,ega_inner_stosb sub    eax,ega_first_last and    ebx,eax pop    eax

DDK\SRC\VGA32\IBMVGA32\CURSOR2.ASM ;Conflicts with the usage of JMP (line 683) and INVOKE statements ;to pointer_off. ;Changed, line 638

;_PtrCode32 SEGMENT DWORD PUBLIC USE32 'CODE' _PtrCode32 SEGMENT DWORD PUBLIC FLAT 'CODE'

DDK\SRC\VGA32\IBMDEV32\THUNK.ASM Vio32SetState PROC SYSCALL,    ;Approx. line 1107 pviopalstate:DWORD,    ;Added, as it conflicts with prototyping hvio:DWORD             ;Added, as it conflicts with prototyping .   ..

DDK\SRC\VGA32\VGAINC\PROTOS.INC ;App. line 902 @OEMDrawBits                    TYPEDEF PROTO SYSCALL, pddcDst       :DWORD, xDst          :DWORD, yDst          :DWORD, psdSrc        :DWORD, xSrc          :DWORD, ySrc          :DWORD, cxExt         :DWORD, cyExt         :DWORD ; These are removed as they do not correspond to the function ; definition : DDK\SRC\VGA32\IBMDEV32\DRAWBITS.ASM ;usMix         :DWORD, ;ipcBkgnd      :DWORD, ;fsBlt         :DWORD In addition to the above, "DCAF" related lines are commented out from the .DEF files and the makefile as instructed in the README file.

3. DRIVER EXECUTION

I have tried different combinations of the the pair of DLL files: ibmdev32.dll and ibmvga32.dll, and must conclude that the DLL file: ibmvga32.dll at the first glance seems to work ok.

The other DLL, ibmdev32.dll causes our system to crash when loaded. Below is the output from the kernel debugger when the system halts: .   .    .    GRE Loading IFI Font C:\OS2\DLL\COURIER.PSF GRE Adding Font to Public Font Table GRE Loading IFI Font C:\OS2\DLL\TIMESNRM.PSF GRE Adding Font to Public Font Table DelayHardError SYS3175: 4 string(s): Pid 0002 Tid 0001  Slot 0008  HobMte 010d C:\OS2\PMSHELL.EXE c0000005 0000000c P1=00000001 P2=0000000c  P3=XXXXXXXX  P4=XXXXXXXX EAX=ffffffff EBX=00000001  ECX=00000000  EDX=14fc0030 ESI=1ac4aa76 EDI=00063fd0 DS=0053 DSACC=d0f3  DSLIM=1bffffff ES=0053 ESACC=d0f3  ESLIM=1bffffff FS=150b FSACC=00f3  FSLIM=00000030 GS=0000 GSACC=****  GSLIM=******** CS:EIP=005a:0000000c CSACC=d0df  CSLIM=1bffffff SS:ESP=004a:00063fd8 SSACC=d0d3  SSLIM=1bffffff EBP=0003f724 FLG=00012206

GRE: Termination routine called. Process exiting. IBMVGA32 Process Exiting. As I am not very familiar with the kernel debugger, do you have any suggestion to what causes this error, and what to look for in order to solve it?

4. IBMVGA32 VARIETIES

The driver located in the directory \DDK\SRC\VGA32\IBMVGA32 can be generated in three different versions: The two first names are obvious, but what is the third?
 * RETAIL
 * DEBUG
 * DEKKO


 * ANSWERS:

1) MASM 6.0 IS required for building 32 bit device drivers. It is what the developers are using here. We are not supplying this assembler in the DDK and I do not know where he can get a copy. Sorry.

2) Thanks for the info.

3) I can't tell the problem from the information given. What he should do is create a KDB.INI file in the root of his boot drive which contains the following two lines: VSF *  G This file will be loaded automatically by the Kernal debugger at boot and tells the debugger to capture all faults. The debugger will then stop on the actual line which causes the trap and display that line. The developer can then enter the 'ln' command to display the name of the routine causing the trap, and the command '.k' to show the call stack. With this information he should be able to figure out the problem.

4) DEKKO - link to the special performance versions of all DLLs for performance testing hooks enabled.

April 5, 1993 - G0022

I have a few questions concerning the licensing agreement of component distribution of modified binaries of the DDK to our SVGA chipset customers (OEMs), as well as possible distribution to endusers (retail customers.)
 * QUESTIONS: (Ref: 210)

1. I would like to modify the source of the SVGA.EXE utility which creates the SVGADATA.PMI file and ship the SVGA.EXE utility ONLY (no source code) along with our PM and VDD drivers. I will retain the IBM copyright message as it currently is displayed. Given the licensing agreement, can I legally do this?

2. If #1 above is yes, can I add my company's copyright as a bi-line to the utility's banner message?

1) The code to SVGA utility can be modified and the executable SVGA.EXE can be shipped with his drivers. The tools referenced in the license agreement that are not allowed to be distributed are only for tools where we do not ship the source code to it.
 * ANSWERS:

2) Yes, he can add his company's copyright statement to the utility as long as he does not remove IBM's copyright statement.

March 16, 1993 - G0018

After reading your specifications for the IFS (installable file system), it appears that we may have a requirement for a somewhat different interface.
 * QUESTION: (Ref: 165)

Our optical disk product currently provides a caching mechanism to magnetic storage. Files on optical disk are copied to a magnetic disk file when they are needed and deleted when they are unused for a period of time. When a user requests a file (DosOpen for instance) the filename is translated into the filename of an entry in the magnetic disk cache and, if necessary, the file is copied into the cache.

Our system then functions better at user level than at kernal since the file I/O required to create a file in the cache must occur at user level. Ideally what we would like to do, is to capture requests at the level of the standard file I/O API; translate the pathname of the requested file (if the request is for our file system); then forward the request to the normal handler for the standard file I/O API.

Is there an existing mechanism for this? From reading the IFS specification it does not appear so.

Is there somebody I can talk to about this? The only calls I believe we would need access to is the Open and Close requests so the level of your support which would be required should be minimal and the performance enhancement over doing this translation at the IFS level via daemons should be significant as we would be saving two ring transitions per file I/O request. This is because we would not trap the read/write calls, only the open/close calls.

There is no way to catch the API and handle it differently than the way it is currently done. The IFS will have to handle the situation.
 * ANSWER:

March 04, 1993 - G0017

I have a few questions on the generation of the drivers. We are using the Microsoft C Compiler version 6.00A and are getting a few different warnings and errors during compilation:
 * QUESTIONS: (Ref: 169)

1. When compiling the file \DDK\SRC\VDH\VDHMAIN.C the compiler outputs the following error message: vdhmain.c (392): warning: C4061: long/short mismatch in argument. vdhmain.c (426): warning: C4059: segment lost in conversion. .   .    . 2. When trying to make the files on \DDK\SRC\PMDISP\EGAFAM the make process terminates beacuse the directory \DDK\SRC\PMDISP\EGAFAM\EGARES is missing.

3. When compiling files on \DDK\SRC\SVDH the compiler output the following error message when trying to process the file svgatype.h: svga.h: warning C4005 'DISPLAY_SVGA' macro redefined. Are the previous mentioned warnings normal?

What is to be done about the missing directory?

1. Compile warnings in vdhmain.c - these warnings are normal and don't hurt anything. Sometimes, when coding in 'C', some warnings are unavoidable due to the way the compiler works. Some warnings can be cleaned up, but are not due to time constraints, and they are harmless. The first warning looks like one of the unavoidable types, while the second usually hurts nothing and can be a real pain to try to cleanup. The driver developers probably left it in due to time constraints when they wrote the code and they have stayed because they did not hurt anything.
 * ANSWERS:

2. Missing EGA directory - yes, the EGA files were not included in the DDK. We left them out because we were concentrating on the newer video technology for now (VGA, SVGA, etc...). To build the EGAFAM stuff, don't just say NMAKE, use the command 'NMAKE VGARET'. This will build only the VGA. This should have been in the documentation, but looks like we left it out accidently.

3. Compile warnings in svga.h - this warning is purely informational and hurts nothing. Sometimes we want to redefine a macro, and this is the compilers way of reminding us that it is already defined.

February 09, 1993 - G0016

I am using non ABIOS machine. Does DevHelp_GetLIDEntry return right value? Do you have definition of return &LID?
 * QUESTION: (Ref: 109)

1) Since the LID (Logical ID) comes from the ABIOS Common Data Area table non-ABIOS returns an error.
 * ANSWER:

2) I don't know what you mean by &LID. The LID is just a handle into the table. A definition of the table can be found in any ABIOS book.

Also, the GetLIDEntry is discussed in the OS/2 Technical Library Physical Device Driver Reference Book on page 17-39.

January 26, 1993 - G0014

In anticipation of the arrival of the OS/2 2.0 DDK CD, I started the development of an OS/2 2.0 driver for a device that is connected to the same cable as the PS/2 mouse. The device "passes through" all true PC-mouse interaction, but monitors the line for its own commands. I would like to purchase the technical documentation of the PS/2 8042 interface.
 * QUESTION: (Ref: 113)

I am not sure whether the BIOS source code would help me out because I don't know if the BIOS has a need to send commands to the PS/2 mouse.

I called around but could not find anybody near the order lines that knew or understood exactly what can be found in the various manuals.

Therefore, my question is: could you please give me the name and part number of the manual that I would need to get? I realize that this may not be an appropriate question to ask on this BBS. In the other hand, after calling around, I am afraid that only you guys could answer that question.

First, you have about as much chance of getting the BIOS source code from IBM as a snowball has in .... (nothing personel).
 * ANSWER:

The information on the commands used to be part of a single document called PS/2 Hardware Technical Manual - Common Interfaces. That manual is no longer available, but has been broken in smaller pieces. I can not be specific as to which of the pieces you need, as I am not sure of your requirements and the content of each. However, here are the form numbers: S84F-9809  PS/2 Technical Reference - Common Interface S84F-9808  PS/2 Technical Reference - Architecture S84F-9807  PS/2 Technical Reference - System Specific S68X-2229  PS/2 Mouse Technical Reference S85F-1646  Technical Reference - AT Bus Systems

January 13, 1993 - G0011


 * QUESTIONS/ANSWERS (Ref: 081)

Q1. We have a problem with generic IOCtls in which we lock the parameters, then lock the data, and the data lock fails but both segments are resident. If we lock only one segment (either one) it succeeds. Why would this happen?

A1. The system does NOT lock request packets or data segments for request packets the device drivers do it themselves. Normally device drivers can not take unexpected page faults (or segment faults) during execution therefore they lock the data.

Q2. Why do segments passed to the driver in the generic IOCtl case need to be locked in the first place? There's obvious cause for care in some cases (e.g. page faults might present reentrancy concerns when the driver is in charge of the device that SWAPPER.DAT lives on), but we don't understand why it's a blanket rule.

A2. It's not a blanket rule, but it's much easier for a device driver to lock the data as opposed to handle unexpected faults.

Q3. How can a driver ensure it's locking segments soon enough? If page faults are indeed the concern, it seems like the driver would have to somehow make sure not to cause any page faults before doing its locks.

A3. Thats why they lock the request packet then lock the data selectors

Q4a. If a segment is already locked, will a second lock succeed?

A4a. Segments or objects can be locked up to 255 times.

Q4b. If so, then does it take n unlocks to truly unlock a segment that's been locked n times?

A4b. Yes, n locks takes n unlocks.

Q4c. If multiple locks are not permitted, what happens when a driver tries to lock a segment that's already locked?

A4c. N/A.

Q4d. Is there a way to tell whether a segment is already locked?

A4d. No.

Q5a. Will OS/2 allow an unlimited number of segments to be locked?

A5a. No, but there is only a finite amount of physical memory to start with.

Q5b. If not, what's the limit?

A5b. OS/2 will allow approximately 7/8 of the total physical memory to be locked.

Q5c. How do you know when the limit has been reached?

A5c. There is no query call, but if a single page lock failed, you hit the limit.

Q5d. What happens when you try to lock another segment when the limit has been reached?

A5d. The lock will fail.

January 6, 1993 - G0010

Question #3: Can you provide any DMA (Intel 8237-5) initialization code for performing memory-to-memory transfers of data? We have tried many ways of using that DMA to perform the memory-to-memory data transfer (using channels 0 & 1 only through the TEMP register within the DMA) without any success in transferring the correct data from one region of the PC memory to another. All we got are "FF's"! We want to use the DMA to perform data transfer from the request packet data section directly into our dual-ported shared RAM and vice versa to increase throughput under OS2/2.0.
 * QUESTION/PROBLEM (Ref: 092)

Answer to Q3: Though the chip may support memory to memory DMA transfers, not all PCs are wired correctly to let this occur. The classic symptom of not supporting memory to memory DMA is getting FFs. This person's machine, most likely, does not support the full function of the chip.
 * ANSWER

December 30, 1992 - G0004

The instructions with the OS/2 2.1 beta CD-ROM state I need to get the file called SYSINS.ZIP. What or where is the IBM OS2BBS?
 * QUESTION:

The IBM OS2BBS is available through the IBM Information Network for DAP Commercial or DAP Premier members. Use account LNK7 for access to IBMLINK.
 * ANSWER:

December 23, 1992 - G0003

How do I get a KERNAL DEBUGGER for the Service Pack code?
 * QUESTION:

Send a letter requesting the DEBUGGER to: IBM Debug Update Attn: Felix Ruo Int. zip 1510 PO Box 1328 Boca Raton, FL 33429-1328 Include a copy of your toolkit license and specify the media desired (3.5 inch or 5.25 inch diskette).
 * ANSWER:

In an emergency, a FAX can be sent to Felix at (407) 982-5049. Include the same information with the FAX.

December 18, 1992 - G0002

Request/release ownership of floppy controller hardware
 * QUESTION//PROBLEM:

The results of my testing so far are:
 * 1) I was unable to interface to the OS2DASD driver from within my loadable driver. It cannot be contacted with IDC and the DosOpen, etc. calls are presumably not valid except at INIT time.
 * 2) I was successful in requesting ownership from the application program by opening "A:"  and sending the requried IOCTL. This requires media in the drive to be successful.
 * 3) The loadable driver was then able to sucessfully do DevHlp SetIrq for IRQ 6.
 * 4) In this mode, I was not able to access the tape drive on the primary controller. By comparison, using the same loadable driver and the exact same hardware, I am able to access the tape if I just remove IBM1FLPY.ADD from config.sys (and don't do the IOCTL).
 * 5) It's not clear to me how DevHlp RegisterStackUsage needs to be used when IRQ 6 ownership is passed back and forth, since it can only be issued at INIT time. Should I not call it for IRQ 6? Do I inherit the parameters established by IBM?FLPY for IRQ 6?
 * 6) I am trying to zero in more exactly on the cause of the problem. I did verify that I was getting the IRQ 6 interrupts, but not why my device was not responding. Is it possible that there is a timer activated routine still, for example, periodically hitting port 3F2 with motor off or something? In DOS we have to keep resetting the timeout count or the floppy routine will reset port 3F2 in the middle of our tape functions. When IBM?FLPY releases IRQ 6 does it output the proper value to 3F2 to tristate the DMA/IRQ?
 * 7) I am continuing to test and try to findout exactly what does and does not work. It may just be a matter of getting the floppy controller correctly reinitialized, etc.

The problem with what you are trying to do is that DevHelp_Attach only works with character device drivers, and not with block device drivers.
 * RESPONSE:

To have the OS/2 device driver unhook IRQ6, you need to issue a DosDevIOCTL call to the device driver. You do that by first getting a file handle using DosOpen, and then using the handle to issue the DosDevIOCTL call. The IOCTL call in question is the one described below.

There is a problem with this method if there is no media in the floppy drive (DosOpen will fail and he won't be able to get a handle to the drive) but you can workaround it by getting a handle to one of the partitions in the hardfile.

Category 8 - Logical Disk IOCTLs

Function 5DH - Diskette Control

This function is used to coordinate exclusive ownership of the diskette controller.

Parameter Packet Format Field                   Length Command Information      BYTE

Indicates whether application is requesting or returning exclusive ownership of the diskette controller.

VALUE        Description 0     Exclusive ownership is returned to the OS/2 disk device driver.

1     Exclusive ownership is requested from the OS/2 disk device driver.

Data Packet Format

Field                   Length Reserved. Set to 0       BYTE

December 16, 1992 - G0001

I am in need of the commercial package for 2.0 LAN Server and any SDK's that are available. What is available, and what versions of OS/2 does it support?
 * QUESTION

There is no LS SDK. The LAN Server product has produced a sold separately publication for Application Developers. It contains not only the Application Program Interface info. but also some sample programs on diskette(s). The order numbers are: Members of the DAP should be able to order the LAN Server 2.0 - Advanced product and the LAN Server 3.0 - Advanced product at a discount through the DAP.
 * RESPONSE
 * LAN Server 2.0 Application Programmers Ref. S04G1046-00
 * LAN Server 3.0 Application Programmers Ref. S96F8440-00

The net of it is that if they want to develop applications that use the LAN Server APIs they will need:
 * 1) The LAN Server product
 * 2) * LAN Server 2.0 - Advanced
 * 3) ** Runs on Standard Edition 1.3 (latest refresh level)
 * 4) ** Supports High Performance File System
 * 5) ** Supports Fault Tolerance
 * 6) ** Supports Local Security on the Server
 * 7) ** Supports OS/2 (16 & 32 bit), DOS and Windows workstations
 * 8) * LAN Server 3.0 - Advanced
 * 9) ** Runs on OS/2 2.0
 * 10) ** Supports High Performance File System
 * 11) ** Supports Fault Tolerance
 * 12) ** Supports Local Security on the Server
 * 13) ** Supports OS/2 (16 & 32 bit), DOS and Windows workstations
 * 14) The API Ref. books
 * 15) * API documentation
 * 16) * Sample programs
 * 17) A distributed feature (right to copy only) for each workstation that the customer requires.

Another publication that may be helpful for those ISVs developing Client/Server applications titled Client/Server Programming in OS/2.

Additional information should be available through the DAP.

October 28, 1992 - CJ280003

Recently obtained access to the Atlanta (apparently public) IBM board. It has various interesting stuff. Number is 404-835-6600. No ADD specific stuff, but many device driver, fix, problems, etc.
 * GENERAL INTEREST:

October 28, 1992 - CJ280001

We're trying to isolate the cause of a hard system crash (black screen, no hardware response, cold boot necessary) that we can provoke on the engineering prototype of a new 486DX2 66MHz ISA-bus machine by running the attached command files (see SWTEST.CMD, which is the main command file) under OS/2 2.0GA.
 * QUESTION:

The machine is configured with 8Mb RAM, S3 86C924 SVGA video chip on the planar running in 640x480x16 mode for the PM desktop. The command files, which must be started from an OS/2 window on the PM desktop, loop on the following command: START /FS NOTHING.CMD where NOTHING.CMD simply issues the command EXIT.

The result is that PM is asked to start as many full-screen OS/2 sessions as possible. On the 66MHz DX2, with the IO delays in the S3 BVHVGA, which are necessary for controlling the speed of the mode switches on the 86C924, PM in fact starts many more sessions in the background than in the foreground.

The basic question that this customer needed answered is: is it reasonable to assume OS/2 is the one failing in this test case...
 * FOLLOWUP:

It is reasonable to assume that OS/2 is setting the screen black in order to display either an Internal Processing Error or TRAPxx message. The most likely possibility, there are others. DVT hardware concerns me.
 * ANSWER:

There are a number of PTRs reported against OS/2 2.0 and trying to identify one from this lack of symptom information is needle in the haystack. Either recommend to the customer to pick up the new service pack (fix everything and see if the problem still occurs) or get more data on symptoms. I reccommend the second.

1. Eliminate the easy answers. Did the processor invoke one of the INTEL architecture trap gates ? This is a quick answer with hardware probes or an ICE machine.

2. Did the system run out of virtual memory (swapfile)? Again an easy answer. Does it occur if I eliminate hardfile space as a constraint?

3. Is the problem reproducable here on similar hardware. Fastest PS/2 or OEM machine running SVGA or VGA?

You have no data to speculate on answers. If this was not new hardware, the clear suspect would be OS/2.

Questions and answers logged before May 1, 1992
ADD Questions and Answers:

1) My Kernel debugger (of 6.147) doesn't work with the current release? What debugger works with the current beta (6.403e)?

Answer: Please contact DAP for the beta update; they will furnish you with the current beta and KDB (We would put KDB on this BBS, but the files are so large it would tie up this BBS for too long)

2) I do not use ABIOS, but your sample code is for ABIOS machines? Could you give some non-ABIOS example code?

Answer: Please look at IBM1S506; it will directly interface with the hardware register set (i.e. it doesn't use ABIOS)

3) What is file IBM2ADSK.SYS?

ABIOS hardfile driver. Refered to earlier as ibm2esdi.sys.

4) I was under the assumption, that our ADD had to handle multiple ASYNC requests from OS2DASD/OS2SCSI.SYS. However, in reading through the code requests are handled at any 1 time. If the state in NOT == IDLE then the read, write or verify request through IOCM_EXECUTE_IO is ignored?

The ADDs are fully asynchronous. In the case of ST506/IDE drives the controller is not capable of operating more than one attached drive at a time. In these cases (also for floppy) the ADD must accept requests for all physical devices it services at anytime. If the device is busy the ADD must queue the request and return immediately to the Device Manager or Filter. It is up to the ADD servicing the device to manage queues for multiple devices attached to a 'non-concurrent' controller.

The ADD model is weighted towards asynchronous operation since this is in line with OS/2 and with both SCSI and ESDI DASD controllers which are capable of running multiple devices concurrently.

5) Can I use 32 bit offsets to my data within an ADD?

No. The ADD programming model is 16 bit, which uses 16 bit offsets.

6) Does 2.0 use the 386 paging feature?

Yes.

7) During initialization, are linear addresses=physical addresses when I use DevHlp_AllocPhys?

No, they are not equal; you will need to use the following call to obtain a logical address in order for the CPU to access the buffer: AllocGDTSelector, PhysToGDTSel.

8) Do I need to use the DevHlps LinToGDTSelector or LinToPageList in my ADDs?

No, these are used by other device drivers which accept Application buffers via the IOCtl interface.

9) What boundries may we expect to see between S/G areas in IBM OS/2 2.0?

4k (same boundries as pages, as implemented on 386 HW)

10) Can MS CodeView (in MSC 6.0) work on OS/2 2.0 (for application debug)?

No, it will trap the system. If you need an application debugger, use the debugger supplied in the C/Set for V2.0 (Contact DAP for details on getting C/Set)

11) When I call the Device Help Routine Register Device Class, I must pass a device class (i.e. Disk, Tape, etc.)  When my adapter has both disk and tape to be supported, do I have to act like two seperate drivers and register as both a disk and a tape and keep two seperate tables?

Currently Register your ADD as Disk; note the only other classification is Mouse (which is unlikely to be supported by SCSI)

12) How do I use CompuServe (CServe) for more Info on device drivers?

Use command GO IBMOS2. Go use the subsections Hardware and 2.0 (in that order) for programming info.

13) Subject: Scatter / Gather

A. When ADD receives the IOCC_CONFIGURATION Command Code, one of the quanities that DPT returns in the ADAPTERINFO structure is MaxHWSGList which defines the maximum # of S/G elements the DPT host adapter supports. Later, when the ADD receives an IOCC_EXECUTE_IO CommandCode which includes a list of scatter/gather elements, can DPT assume the the count of S/G elements will not exceed the MaxHWSGList value?

B. Assuming that the answer to #1 above is `yes', if DPT sets MaxHWSGList = 64 (which the DPT host adapter can support), will OS/2 ever send any I/O request with that many S/G elements? The reason DPT asks this is that they assume they will wast a lot of system RAM if they provide for 64 S/G elements most of which can never occur. Because the DPT host adapter can handle up to 64 simultaneous I/O requests each with 64 S/G elements, each 8-byte S/G element which is not needed wastes 64*8=512 bytes times the # if host adapters present.

There is no limit on the number of S/G elements passed. However, the Device Managers will insure that the element at multiples of MaxHWSGListLength will not cross a LBA boundary. This allows the ADD to break up requests that exceed the maximum S/G HW list length into separate requests.

For CDB passthru requests the the ADD may assume that a passed S/G list will not exceed MaxHWSGListLength.

Further more, the ADD may modify the passed S/G list provided it reverses any modifications prior to notifying the Device Manager. The ADD would not normally incur any additional storage costs in this case.

THESE QUESTIONS CONCERN TIMER SERVICES:

Based on what is in ADD spec, looks like the ADD is responsible for setting up And handling I/O request's timing. (See Timeout value passed in IORBH)

14) The IBM2FLPY ADD uses DevHlp calls to handle timing. The AHA154X ADD also uses calls to the ADDCALLS library. Which is the recommended approach?

(A) It is recommended that you use the services in the ADDCALLS library. However, there is no requirement to do so. You may find that usage of the Timer functions is convenient when the ADD needs to manage a number of independent timers.

Due to overlap in the writing of the ADDs and the development of the library services, some ADD writers opted to implement the services themselves.

15) Is there documentation available on the ADDCALLS library functions?

(A) Documentation for the library services will be included in the Beta development kit which is currently being developed.

16) If DevHlp calls are to be used, are the following calls accurately described in Chap 17 fo the "Physical Device Driver Reference". DevHlp_SetTimer, DevHlp_ResetTimer, DevHlp_TickCount, DevHlp_GetDOSVar

(A) DevHelps are as described in the PDD Reference. When an error condition occurs (cy) is set by the library interface routines or 0x8000 to the returned value in AX. The C-function prototypes for the DevHelps is provided in \DISKH\DHCALLS.H. The source for the library interface routines is in \DEVHELP.

DevHelp_GetDOSVar has an additional variable to access the table of registered ADDs this is discussed in the ADD/DM Specification.

17) If using DevHlp, how do I determine timer tick interval at initialization time since the DevHlp_GetDOSVar description says that GlobalInfoSeg.Interval is valid only at task and interrupt time?

(A) ADDs may use interrupts and timer services and may block during initialization. However, when an ADD completes processing a request it should unhook its interrupt vector since the OS/2 KERNEL will mask interrupts to real mode while a protect mode driver has the interrupt hooked.

THESE QUESTIONS CONCERN SPINLOOP VS INTERRUPT HANDLING

18) During initialization and assumed, some initial I/O requests, INT 13 is being used by the system to load various modules from the booting disk. During this time, I/O performed by the ADD cannot use interrupts but must complete so that interrupts may be used?

If I register my IRQ prior to INT 13 complete, will system start calling my interrupt service routine immediately? In LADDR I had to wait for Boot Complete (no more INT's) before registering my IRQ so as not to get interrupted for I/O request that I did not make.

(A) Although a number of people have reported that on 1.x systems, they received spurious interrupts from REAL MODE INT 13 activity, this is NOT the case in 2.x systems. The kernel (DOSHLP) component blocks interrupts for hooked IRQs. This 'feature' is being reviewed, at this time. For the time being however, you should hook and unhook the IRQ vector until you receive a COMPLETE_INIT IORB after which you may leave the vector hooked permanently.

19) Subject: ADD Filter Question

(1): I have some questions relating to the ADD spec Appendix A page 22, RequestControl flags. I have noticed that IBM2ADSK only allows EXECUTE_IO requests to be chained, it will only handle EXECUTE_IO asynchronously. All other requests cannot have IORB_CHAIN set and are handled synchronously. However, IBM1S506 processes all requests asynchronously (depending on the internal ADD's processing state, where if it is not busy they would be done synchronously) and allows chaining. Who is right here?

Could I have some clarification of the ADD spec when it is available. (I could look at OS2DASD, but that would make this a defacto specification.)

(2): There seems to be an interface mixup between OS2DASD's call to the ADD Entry Point, and its definition. All ADD's given as source have the ADD entry point defined as C type (which does NOT clean parameters off the stack). However OS2DASD defines all calls to the ADD Entry Point as PFN (PASCAL type) which has the callee clean off the stack. I have redefined calls to the ADD entry point as : (_cdecl FAR *) to allow my filter to call any C based physical ADD entry points. Please clarify this with me.

(3): I have some concern about the fact that OS2DASD and the ADD architecture will make it into the GA release. I am relying fully on ADDs for the implementation of my product, and we are pushing for an April 1992 release. If OS2DASD does NOT make it into GA, I need a fallback. Is it possible to get the source code for DISK01 and DISK02 as a bridge from GA to the availability of OS2DASD to my customer base???

(4): I am having a problem running my filter ADD w/ OS2DASD. Apparently due to OS2DASD.DMINIT.C.Read_Sector function not using the proper IORB structure to check the return code. See enclosed code: /* - - - - - - - - - - - - - - - - - - - - - - - - - - - - ; ;** Read_Sector - performs disk reads during initialization ; ;  Reads a sector from a fixed disk into ScratchBuffer. ;  This routine sets up a hard coded read request packet ;  and calls the Adapter Driver to perform the read. ; ;  USHORT Read_Sector (NPVOLCB pPhysVolCB, ULONG rba) ; ;  ENTRY:    pPhysVolCB       - Physical VolCB of disk to read ;            rba              - RBA of sector to read ; ; ;  RETURN:   USHORT           - Result Code (NO_ERROR if successful) ; ;  EFFECTS:  Reads a sector into global variable ScratchBuffer. ; ;  NOTES:    This routine is DISCARDED after init time. ;- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

USHORT Read_Sector(pPhysVolCB, rba)

NPVOLCB pPhysVolCB; ULONG   rba;

{   PRP_RWV  pRP; NPIORB  pIORB; NPUNITCB pUnitCB; USHORT  rc;

/* Set up the request packet for the read */

pRP = &InitTimeRP; pRP->rph.Unit = pPhysVolCB->PhysDriveNum; pRP->rph.Cmd = CMDINPUT; pRP->rph.Status = 0; pRP->MediaDescr = MEDIA_FIXED_DISK; pRP->XferAddr = ppScratchBuffer;     /* Point to scratch buffer */ pRP->NumSectors = 1;                 /* Read 1 sector */ pRP->rba = rba;                      /* Store rba */

pUnitCB = pPhysVolCB->pUnitCB;

pIORB = (NPIORB) InitTimeIORB; f_ZeroCB((PBYTE)pIORB, MAX_IORB_SIZE);

SetupIORB(pUnitCB, (PBYTE) pRP, pIORB);

///LOOK HERE ********* - Call uses pIORB to call ADD !!!!!!!

(pUnitCB->AdapterDriverEP) ((PVOID) pIORB);

DISABLE;

///LOOK HERE ********* - Call uses pRP to test if done !!!!!!! /// I think this is a bug., it should use pIORB???

while ( !(pRP->rph.Status & STDON) )   /* Loop until I/O done   */ {      DevHelp_ProcBlock ((ULONG)pRP, -1L, 1);  /* Block: No timeout,non-interru DISABLE;                         /* Block does an enable  */ }

ENABLE;

if (pRP->rph.Status & STERR)         /* Check for error */ rc = ERROR; else rc = NO_ERROR;

return(rc); }

19) Answer

1.) The RequestControl Flag IORB_CHAIN will only be set in EXECUTE_IO requests. This will be clarified in the next revision of the spec.

2.) An ADD may not block but does have the option of processing requests synchronously (i.e. returning with Status = IORB_DONE) or using the Notification Callout mechanism. There is no spec requirement to use one mechanism or the other. The choice is up to the ADD writer, depending on how long it will take the ADD to service the request.

3.) The ADD/DM specification is the standard, not the sample code IBM provides! Precedence of the various materials IBM provides is discussed in the next revision of the spec.

4.) The ADD interface and Notify interfaces specifications have been corrected. They both use C calling conventions not PASCAL.

5.) IBM is fully committed to providing ADDs on the GA product. ADDs will ship in the next BETA OS/2 release. DISK01/02 and DSKBIOS1 have been withdrawn and will not appear on the product diskettes.

6.) The OS2DASD code is correct. The DONE bit in the RP status field is set by the Notification Callout routine of the IORB that the DASD Manger is waiting on. Your Filter ADD must call the Notify routine if IORB_ASYNC_POST is set in the control flags. If you do not do this, the system will hang as you indicated. In addition you must the IORB_DONE bit in the IORB Status prior to calling the notification routine.

Handling of IORB_ASYNC_POST is required for all IORB commands, this has changed from the revision of the spec you currently have

20) I have uploaded the most recent version of the ADD toolkit, but it seems to malfunction under 6.147. What's the problem?

Answer: The ADDs and DMs currently on the BBS will work with 6.304e, which is currently being distributed by DAP; please contact them in order to receive this release.

21) How does the INT 13 ADD know which other ADDs have control of devices 88H and 81H??

It doesn't. The action taken depends on the number of bios drives. If the count of bios drives is...
 * 0 - int 13 controls all hardfiles with bios
 * 1 - int 13 controls all hardfiles with bios but 80
 * 2 - int 13 controls all hardfiles with bios but 80 and 81

etc.

22) Install DISK configuration on a NCR 486 MCA, w/ an NCR SCSI busmaster, they attempted to use INT 13 ADD (in addition to the OS2DASD.SYS.). this configuration hung the system with the error message; "DISK READ ERROR, PLEASE RESTART MACHINE".

Please insure Steve Hudson tests our drivers on this configuration. We are continuing to fix bugs.

23) The IBMOS2 forum on CompuServe has several updated ADD drivers. Will the sources found on this OEM BBS build equivalent or later drivers?

The ADD source on this BBS is the latest downloaded from the designers nodes; please check the files dates. Note that the current BBS are updates of those ADDs being distributed on CServe.

24) Does the Workplace Shell add an "Eject" option to a removable drive in the Drives Folder? Not at this point in time.

If so, does the option grey out when the drive is not ready?

If not, how does one add the option to the drive object or do I need to supply a separate eject utility?

Seperate utility.

25) Is there a mechanism to support removable drives with HW pushbutton eject support?

We have two controllers to support, one supports removable drives with NO HW eject support. The other controller supports removable drives with an eject button. When the button is pressed, an interrupt is generated and my driver determines that the user wants the drive ejected. I need a DevHelp or other call to notify the OS about the situation. I know that ejecting the drive without flushing its File System buffers and unlocking it will surely cause havoc. Any suggestions?

Removeable media DDs need to sense change of media; there are two methods to do this:
 * 1) HW changeline support (which apparently your HW doesn't handle)
 * 2) Timed routines
 * We recommended that your DD checks time after IO is finished and your hardware is not executing any operations; when the next IO request comes along, your DD checks the time again... If the more than 2 seconds have passed, return an error code (ECode) unknown media (since you cannot assume what volume is present after 2 seconds (which is minimum time to switch disks)) Get the time with DevHlp GetDOSVAR.
 * The kernel will sense this ECode (Unknown media) and send down the appropriate RPs to flush buffers, read volume names, and generally cleaning house.

26)

We strive to develop drivers to support our removable hard disk drives. Our hard disk drive must be usable under DOS 5.0 and OS/2. After getting my driver to handle my removable hard drives as fixed disks, I attempted to start my testing the removable aspects of the driver.

1 - If the removable bit is turned off in the UnitFlags field of the AdapterInfo structure, the unit is seen as a fixed disk with a partition table as one would expect. If the bit is turned on, the unit is seen as a large floppy and OS/2 is expecting to see a boot record at sector 0. This is totally unexceptable. Our drives must be usable under DOS (when formatted for the FAT file system). Our DOS drivers (available for several years) require the removable media to have the same structure as a fixed disk. A solution to this would be to have another bit which indicates that the removable media also has a partition table (the DM would have to take care of this).

2 - If the removable bit is on, then there is no way one can create a removable disk that has the HPFS format. This is also unexceptable. I was able to create HPFS removable drives under OS/2 1.x and I definitely expect to do the same under OS/2 2.0.

4 - Since our removable disk drives require Master boot records with partition tables, they must be visible under FDISKPM. FDISKPM could be made allow only one partition on the drives that are removable. FDISKPM must also come up if one of the physical drives report a Not-Ready state. FDISKPM currently fails to run if any physical drive is not-ready. It in turn should come up and not allow any I/O to the not ready drive. These changes are not hard, I did them for OS/2 1.x.

You are running into design points that are being reviewed.
 * Answer

1,2,4 - Our current Volume mounting/shutdown design needs to be reworked before we can allow removable media to be partitionable. A requirement for this functionality needs to be sent to Jeff Dean's planning group so that it can be considered for one of our next releases. HPFS is currently coded to assume it will be working on non-removable media, You may have been able to "format" and "use" a removable HPFS volume, but if any writing is done to such a volume, allocation errors WILL BE PRESENT on it when it is removed. There is currently consideration to make HPFS work on Magno-Optical drives.

3 - The device manager MUST support some form of request from ring 3 (an application or FSD) to eject the media. What would be ideal is a new DOSEject function that would except either the physical drive number or the logical drive letter and then issue a request to the FSD to flush its cache buffers before sending the eject request to the ADD. Tandon has some removable drives that can only be ejected via software command!!!

5 - This type of removable device should have its own icon on the Workplace Shell. This icon should have an additional menu item "eject" that would call the DOSEject function.

3,5 - There is a EJECT/DRIVE NOT PRESENT requirement against OS/2 from the lab. The eject function is for the Magno-optical drives, and the not present is for powered off SCSI drives.
 * Answer

Administrative Stuff for this Q and A File

 * October 27, 1993 - G0032
 * April 5, 1993 - C0026
 * February 23, 1993 - B0002
 * June 28, 1993 - M0010
 * October 26, 1993 - P0001