blp@inuxh.UUCP (Bruce Paramore) (11/03/88)
I am having a problem with a DOS device driver I have written. All it has to do for my present application is to write a byte to a register on a custom board. This seems to work fine for all values except 0x1a (^Z). I have written a small print routine to tell me when I enter my driver, and when I pass the 0x1a to DOS, my driver is not entered, and a value of 0 is returned for the bytes written. I am using MS-DOS 3.3. Can anyone give me ideas on what may be causing this problem? The driver was supposed to handle some timing considerations in the future, but if I can't solve this problem soon, I'll need to do I/O writes directly from the application :-( bruce paramore att!inuxc!blp
dixon@control.steinmetz (walt dixon) (11/05/88)
There are basically two i/o paths through DOS -- character i/o functions (ah=01h to 0ch) and other i/o functions. The character i/o requests transfer a single character directly to the driver. DOS does not mess with the text stream. Writes to CON, AUX, or PRN using these functions should pass 1ah (^Z). The second i/o path encounters a DOS internal write routine. This routine looks at some attributes in an internal DOS data structure called the System File Table (SFT). If the target dis a device and it is not in transparent mode, each character is checked. If an EOF (^Z) is detected, an EOF status is set in the SFT and the write returns without sending the character to the device. If the device is in transparent mode, DOS does not check the character stream. The LSB of the driver attributes word is copied to the SFT when the driver is open. DOS specifically masks the bit corresponding to transparent mode, so you can not set this bit in your driver unless you (*GASP*) patch DOS. Such drastic action is normally not required, because one can easily put a device into transparent mode with an IOCTL request. Once in transparent mode, DOS will faithfully pass all characters to your device. You should be aware of one side effect of transparent mode. In text (ie non transparanet) DOS passes one character at a time to the driver because it is looking for special (ie ^Z) characters. In transparent mode, DOS passes the entire request. The bottom line is you really need to look at the count field in the request header. Walt Dixon Standard disclaimers apply
hollen@spot.megatek.uucp (Dion Hollenbeck) (11/07/88)
From article <712@inuxh.UUCP>, by blp@inuxh.UUCP (Bruce Paramore): > I am having a problem with a DOS device driver I have written. All it has > to do for my present application is to write a byte to a register on a custom > board. This seems to work fine for all values except 0x1a (^Z). I have > written a small print routine to tell me when I enter my driver, and when > I pass the 0x1a to DOS, my driver is not entered, and a value of 0 is > returned for the bytes written. I am using MS-DOS 3.3. > DOS is looking at ^Z and saying "Oh, he means end of file, don't send this". You might be able to get around this by picking any other control character (or maybe a sequence) and having your device driver translate it into the register as ^Z, otherwise, DOS will continue to eat it for you. Dion Hollenbeck (619) 455-5590 x2814 Megatek Corporation, 9645 Scranton Road, San Diego, CA 92121 seismo!s3sun!megatek!hollen ames!scubed/
dave@westmark.UUCP (Dave Levenson) (11/11/88)
In article <395@megatek.UUCP>, hollen@spot.megatek.uucp (Dion Hollenbeck) writes: > From article <712@inuxh.UUCP>, by blp@inuxh.UUCP (Bruce Paramore): > > I am having a problem with a DOS device driver I have written. All it has > > to do for my present application is to write a byte to a register on a custom > > board. This seems to work fine for all values except 0x1a (^Z). ... > DOS is looking at ^Z and saying "Oh, he means end of file, don't send > this". You might be able to get around this by picking any other control > character (or maybe a sequence) and having your device driver translate > it into the register as ^Z, otherwise, DOS will continue to eat it for MS-DOS allows an application to place a device in RAW mode. The ioctl function call supports this if your driver does. The trouble is that there is no way to use it from the command line (no stty command) and no ioctl() library function provided in MS C. But you can do it yourself (in assembly language, or by using intdos() in C) in your application, after you've opened your custom device. Have a look at dos function 0x44: Bit 5 of the value passed in register DX is the RAW/COOKED flag for the device. -- Dave Levenson Westmark, Inc. The Man in the Mooney Warren, NJ USA {rutgers | att}!westmark!dave