Device Driver FAQ
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.
Legend:
Topic areas can be keyed using "<name>" or in general by "*****". Individual questions can be keyed using "_____" (note: underline char, not dash). Specific questions can be keyed using given sequence number (eg: "CA010000").
The following unique strings areas are supported in this file:
STRING AREA ====== ====== <CDROM> CDROM <DISPL> Displays in general <GEN> General Device Driver <SCSI> Small Computer System Interface <SVGA> Super Video Grapics Adapter <TAPE> Tape Device Drivers <MOUSE> Mouse and Pointer Devices <OTHER> General OS/2 and Hardware Stuff <OLD> Questions and answers logged before May 1, 1992 <GEN> ********** General Device Driver *********************************
OCTOBER 27, 1993 G0032
- QUESTION (Ref 572)
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.
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.
- ANSWER
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.
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.e
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?
ANSWERS:
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.
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
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.
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.
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
QUESTION: (Ref 209)
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?
ANSWER:
The driver is at ring 0 and has access to all DevHelp routines documented for PDD.
March 29, 1993 C0025
QUESTION: (Ref 100)
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.
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?
ANSWER:
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.
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
QUESTION: (Ref: 140)
How can I issue error messages from a device driver after initialization time?
ANSWER:
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. 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.
QUESTION:
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?
ANSWER:
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
February 26, 1993 C0018
QUESTION: (Ref 099)
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
ANSWER:
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.
QUESTION:
What is interrupt simulation for VDDs?
ANSWER:
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.
QUESTION:
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?
ANSWER:
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". 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.
QUESTION:
Can the Dos idle settings be used to affect the priority of a VDM?
ANSWER:
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.
QUESTION:
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.
ANSWER:
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.
QUESTION:
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.
ANSWER:
Instead of using ON and OFF, use 1 and 0. For example, "COM_HOLD=1".
QUESTION:
Will VDDs developed for OS/2 2.0 need to be recompiled with 2.1 headers to work properly under OS/2 2.1.
ANSWER:
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.
February 23, 1993 B0002
QUESTION: (REF:135)
I have two questions regarding the 16 meg boundary. We are developing a add to support all ISA/MCA and EISA scsi host adapters.
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 ?
ANSWER:
All allocations done thru 16 bit devhlps (that deal with memory, ie allocphys, lock etc) will return buffers below 16 meg. 32 bit devhlps (ie 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.
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
QUESTION: (Ref: 140)
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.
1. Can we use dosapi call DosPutMessage during task time and interrupt time from the add?
ANSWER:
1) No, physical Device Drivers are only able to use the DEVHELP API's after INIT time.
QUESTION:
2. In which library are dos api calls built in ?
ANSWER:
2) Available from PDK but once again only good for applications.
QUESTION:
3. How do they interface with the kernel ?
ANSWER:
3) Ring 3 call gate.
QUESTION:
4. Is it the same way as DevHelp calls ?
ANSWER:
4) No, DEVHELP is a single call gate at RING 0.
February 16, 1993 C0016
QUESTION: (Ref 014)
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.
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.
ANSWER:
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.
February 16, 1993 C0015
QUESTION: (Ref 139)
1. I need to get EISA configuration ( BIOS INT 15h function D8h in DOS) how I get it in os2 ?
ANSWER:
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. 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.
QUESTION:
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) ?
ANSWER:
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. 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.
QUESTION:
2. Im also need to make DMA transfre between the buffer and the user buffer what is the best way to do it ?
ANSWER:
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.
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
QUESTION: (Ref 138) 1. How I Use The Bios Service, for example Int 15h, from PDD ?
ANSWER: 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.
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?
QUESTION: Memory Allocation Problam 1. I Allocate memory with the DevHelp Function VMAloc of
Contiguous memory an also (Fixed all Time) from System memory eg 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 VMAloc) Instead of 8 pages of 0x1000 KB ?
ANSWER: 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.
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 QUESTION: (Ref: 060)
Having problems with transfers of data >64K between an application and a device driver.
ANSWERS:
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.
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 QUESTIONS: (Ref: 046)
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:
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?
ANSWERS:
Answer to Q1: This cannot be done by a user written VDD at this time. It is a known requirement.
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 QUESTIONS: (Ref: 099)
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?
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?
ANSWERS:
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.
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 QUESTION: (Ref: 091)
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.
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
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?
Could you please provide some example code in C and assembly for the above question? Thank you.
ANSWER:
FOR THE VDD -
In one file:
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 OS2/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 ?
ANSWERS
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.
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 QUESTION: (Ref #76)
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, ie 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.
ANSWER:
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.
December 15, 1992 C0007 These questions regard OS/2 Adapter Device Drivers.
QUESTION: Does OS/2 ever request byte counts in a scatter/gather entry which are not multiples of 512?
ANSWER:
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.
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.
QUESTION: 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?
ANSWER:
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.
November 17, 1992 BK16002
PROBLEM/QUESTION
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).
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;
RESOLUTION
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().
October 28, 1992 CJ280005 Question:
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.
Answer:
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. 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 QUESTION: I am having trouble finding documentation on OS/2 2.0 IOPL segments. Under earlier versions of OS/2, IOPL (ring 2) stacks, alocated for DLL's, 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.
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?
FOLLOWUP: Background: An IOPL segement is .... An input/output privilege level executable section of programming code that enables an application to directly manipulate hardware interrrupts and ports without replacing the device driver.
ANSWER:
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. 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 ande
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
<CDROM> ********** CDROM *******************************
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)
<DISPL> ********** 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?
ANSWERS:
1) You need to run DSPINSTL. This utility updates the INI files to point
to the new drivers, as well as installing them.
2) The DSPINSTL utility and procedures are available on the new DDK
available May 25 for Spring Comdex.
June 28, 1993 M0007
QUESTIONS: (Ref: 255)
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?
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.
ANSWERS:
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.
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
QUESTION: (Ref: 253)
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.
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 QUESTION: (Ref: 251)
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.
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.
ANSWERS: 1) Yes, they are supported.
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?)
ANSWERS:
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.
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.
ANSWER
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.
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.
<SCSI> ********** 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?
ANSWER:
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.
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:
SCSI.INF
ADD Command Line Parameters
Syntax Conventions
SCSI-Specific Parameters
If your product requires these parameters in config.sys in order to
operate successfully, then you will need to document this for your
customers.
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 QUESTION: (Ref: 204)
We are developing an ADD SCSI driver for OS/2 2.0.
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?
ANSWER:
GDT is Global Descriptor Table which is selectors array.
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
QUESTION: I am writing an OS/2 2.0 driver for SONY optical drives. SONY has seperate 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.
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 QUESTION: (Ref: 110)
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 adaptor. This all works fine.
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
PROBLEM/QUESTION
Timeout during test of ESC2ADD SCSI device driver.
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).
RESOLUTION 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.
<SVGA> ********** Super Video Grapics Adapter **************************** __________________________________________________ May 6, 1993 M0002
QUESTION: (Ref 238)
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.
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 dll's.
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.
ANSWER:
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.
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
QUESTION: (Ref: 208)
NEW BACKGROUND MIXMODES FOR BITBLT
1.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 code.
.\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.
__________________________________________________ January 5, 1993 G0008 PROBLEM/QUESTIONS (Ref: 075) I have a few questions regarding the SVGA DDKs. They are:
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
resolut ion 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.
ANSWER
Question 1:
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 DLL's 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> ********** Tape Device Drivers ****************************
__________________________________________________ November 5, 1992 BK02001
PROBLEM/QUESTION 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.).
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?
RESOLUTION 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.
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> ************* 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?
ANSWERS:
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.
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
QUESTION: (Ref #116)
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. 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?
ANSWER:
1) No. 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?
ANSWER:
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.
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.
<OTHER> ************* 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:
- RETAIL - DEBUG - DEKKO
The two first names are obvious, but what is the third?
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 QUESTIONS: (Ref: 210)
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.)
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?
ANSWERS:
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.
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 QUESTION: (Ref: 165)
After reading your specifications for the IFS (installable file system), it appears that we may have a requirement for a somewhat different interface.
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.
ANSWER:
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.
March 04, 1993 G0017 QUESTIONS: (Ref: 169)
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:
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?
ANSWERS:
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.
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 QUESTION: (Ref: 109)
I am using non ABIOS machine. Does DevHelp_GetLIDEntry return right value? Do you have definition of return &LID?
ANSWER:
1) Since the LID (Logical ID) comes from the ABIOS Common Data Area table non-ABIOS returns an error.
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 QUESTION: (Ref: 113)
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.
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.
ANSWER:
First, you have about as much chance of getting the BIOS source code from IBM as a snowball has in .... (nothing personel).
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/PROBLEM (Ref: 092) 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.
ANSWER
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.
December 30, 1992 G0004 QUESTION:
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?
ANSWER:
The IBM OS2BBS is available through the IBM Information Network for DAP Commercial or DAP Premier members. Use account LNK7 for access to IBMLINK.
December 23, 1992 G0003 QUESTION:
How do I get a KERNAL DEBUGGER for the Service Pack code?
ANSWER:
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).
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 QUESTION//PROBLEM: Request/release ownership of floppy controller hardware
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.
RESPONSE:
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.
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 QUESTION 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?
RESPONSE 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:
- LAN Server 2.0 Application Programmers Ref. S04G1046-00
- LAN Server 3.0 Application Programmers Ref. S96F8440-00
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.
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
- LAN Server 2.0 - Advanced
. Runs on Standard Edition 1.3 (latest refresh level)
. Supports High Performance File System
. Supports Fault Tolerance
. Supports Local Security on the Server
. Supports OS/2 (16 & 32 bit), DOS and Windows workstations
- LAN Server 3.0 - Advanced
. Runs on OS/2 2.0
. Supports High Performance File System
. Supports Fault Tolerance
. Supports Local Security on the Server
. Supports OS/2 (16 & 32 bit), DOS and Windows workstations
2. The API Ref. books
. API documentation
. Sample programs
3. 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 GENERAL INTEREST: 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.
October 28, 1992 CJ280001 QUESTION:
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.
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.
FOLLOWUP:
The basic question that this customer needed answered is: is it reasonable to assume OS/2 is the one failing in this test case....
ANSWER:
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.
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.
<OLD> *********** Questions and answers logged before May 1, 1992 **********
No date ADD Questions and Answers:
No date 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)
No date 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)
No date 3) What is file IBM2ADSK.SYS ????
ABIOS hardfile driver. Refered to earlier as ibm2esdi.sys.
No date 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.
No date 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.
No date 6) Does 2.0 use the 386 paging feature?
Yes.
No date 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.
No date 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.
No date 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)
No date 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)
No date 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)
No date 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.
No date 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.
No date 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)
No date 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.
No date 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.
No date 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.
No date 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.
No date THESE QUESTIONS CONCERN SPINLOOP VS INTERRUPT HANDLING
No date 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.
No date 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 reuests 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
No date 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.
No date 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.
No date 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.
No date 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.
No date 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.
No date 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.
No date 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.
Answer;
You are running into design points that are being reviewed.
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.
Answer;
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.
<ADMIN> *********** 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 �