DOS Device Drivers
Dear DDJ,
I read with interest Jim Kyle's article, "Loading Device Drivers from the DOS Command Line" (DDJ, November 1991), as I had written such a utility in the past. What I found during my experience may prove to be useful to others planning to make use of such a program.
When loading device drivers which are to control system files/devices, and which are also likely to notify DOS of critical error occurrences (PRN and AUX, for example), supplemental logic is required to install such character devices safely. When a driver meeting the above criteria returns an error to DOS, the user is presented with the Abort, Retry, Ignore/Fail message. If the retry option is chosen, control returns to the driver that is pointed to by the driverptr field in the SFT (system file table) entry for the corresponding file/device, which may or may not be the driver which notified DOS of the error. When DOS loads a driver via a config.sys device=entry, it sets the driverptr field to the segment: offset of the driver's address and the starting cluster field to the offset of this address also. Listing One, page 149, demonstrates the method of overcoming this problem. A call to this routine should be inserted in the GetOut routine for character device installations.
I hope some of you find this a helpful addition to this handy utility.
Dan Winter
Stratford, Ontario
Sound Suggestions and Fourier Facts
Dear DDJ,
Listing Two, page 149, shows my quick and dirty approach to the speech-to-PC speaker discussion that began in the January 1992 "Letters" column. It was assembled using the Microsoft Assembler, and was tested in Turbo C++. Its C++ function prototype is:
extern "c" void far VoiceTrk(unsigned char huge *strt, int leng);
where strt contains the start location of the sample bytes and leng is the number of sample bytes in the track. The audio track was digitized using a Sound-Blaster Pro sound board.
The function establishes a sample period which is however long it takes my 386SX to count down from 32 in the outer loop. With the processor running at 16 MHz, this results in a sample period of approximately 6300 Hz. Pulse-width modulation is accomplished by turning the speaker on at the beginning of the sample period, and turning it off when the value of the sample, truncated to 5 bits, has been counted out. The speaker then remains off for the remainder of the 32 counts in the sample period.
Note that interrupts are suppressed with the CLI instruction before playing the audio track and set afterward with STI. This temporarily inhibits the 18.2-Hz time-of-day interrupt which otherwise produces a warble when music is played. I have used this function to play speech, as well as Bach, with tolerable success considering the relatively poor quality of the speaker system.
I would also like to comment on Mac Cody's April 1992 article, "The Fast Wavelet Transform." Mac makes several erroneous statements about the Fourier transform, perhaps confusing it with the Fourier series.
The Fourier transform makes no assumptions about the periodicity of the function being transformed. This transform was originally developed for probability theory. The Fourier transform applied to a correlation function produces the spectral density function for a given random process. Correlation functions are not, in general, periodic. It therefore has no difficulty with transient functions. One of the most often seen transforms is that of the rectangular pulse centered at the origin, which gives the well-known (sin x)/x spectral function.
Also, sharp transitions do not prevent the integral from converging if the function being transformed satisfies the Dirichlet Conditions, which require that the function have a finite number of finite discontinuities, and a finite number of finite maxima and minima, in any finite interval of the independent variable.
Similarly, the Fourier transform takes into account any translation of the function in time. If a time function f(t) has a transform F(w), then the time function translated in time is f(t-a), and its transform is exp(-jwa)F(w).
Digital algorithms designed to implement the Fourier transform may suffer from the problems Mr. Cody describes, but the transform itself does not.
Harold M. Martin
Houston, Texas
Mac responds: Mr. Martin brings up some valid points with respect to the Fourier transform vs. the Fourier series (and for that matter, the discrete Fourier transform, or DFT). In digital signal processing applications, the term "Fourier transform " is often synonymous with the fast Fourier transform (FFT) algorithm. Please excuse my slip in the use of terminology. The assumption of periodicity of a function indeed lies with the Fourier series.
The Fourier series is closely related to the DFT. Both share the same periodicity assumption. The FFT is simply an efficient algorithm for the calculation of the DFT. Therefore, the issue of implied periodicity is real to those who use the FFT.
The problem that the Fourier transform (as well as the Fourier series, DFT, and FFT) has with the treatment of transient (especially discontinuous) functions is that a transient event in the original function results in nonzero coefficients throughout the Fourier transform as a distribution of the function's energy throughout the Fourier spectrum. This tends to "mask" the existence of the transient elements of the original function.
In the original draft of my article, I illustrated the differences between the Fourier transform of a continuous sinewave vs. a sinewave pulse. The Fourier transform of the sinewave is a single nonzero coefficient at the frequency of the sinewave. On the other hand, the Fourier transform of a sinewave pulse is the (sin x)/x function centered on the frequency of the sinewave. The Fourier transform does not intuitively convey the nature of the sinewave pulse, which is a single frequency existing for a finite length of time. I am not saying that the transform is incorrect; according to Fourier theory, it is correct. What I am saying is that the process of mapping transient events into spectral distributions hides or embeds them along with the rest of the spectral content of the transform. The transient components cannot then be easily discerned within the spectrum.
Mr. Martin's reference to the shift theorem of the Fourier transform [translation of a function, that is, f(t-a), yields the transform exp(-jwa)F(w)] is also valid. Most applications of the FFT, though, use the magnitude of the transform, which is invariant with time shift. Use of the unmodified real and imaginary components (or the phase) of the transform to maintain the time relationships is possible but inconvenient to use. In addition, the information related to specific transients is still buried within the body of the transform.
While it is true that the Fourier transform itself may not suffer from some of the problems described in my article, and addressed in Mr. Martin's letter, the digital algorithms which implement the Fourier transform do. These algorithms are used in real-world digital signal processing applications (which is, ultimately, what we're concerned with) and the user must recognize and contend with their limitations. The ability to overcome these limitations is what makes the wavelet transform and its fast algorithms so attractive.
GATT Real
Dear DDJ,
The April 1992 editorial, "Born in the USA," misstates the truth about GATT. Apparently Mr. Erickson thinks that when the revised GATT is presented to Congress there will be no opportunity to debate the merits of software patents.
Most legal experts agree that software patents were made possible by the 1981 Supreme Court decision Diamond vs. Diehr. The Uruguay Round of GATT negotiations began over eight years ago. Thus, the software industry had ample time to lobby the President and the U.S. Trade Representative for changes in U.S. law or GATT. Congress had plenty of time to revise U.S. patent law. Neither the industry nor Congress have acted.
This inaction indicates that intellectual property owners, and the majority of the software industry, support patents in the U.S. and abroad as a way to preserve U.S. market share and protect America's intellectual assets. GATT will not "force sweeping changes" on the U.S.; it will harmonize intellectual property law, enabling continuing protection of America's creative, economically valuable software engineering community.
Christopher J. Palermo
Patent Attorney
Pasadena, California
Jonathan responds: Thanks for the clarification, Christopher. I've stated several times that the problem is less with the issue of intellectual property rights, but more with the way the patent system works. It seems that the only parties satisfied with the current state of affairs are lawyers who appear to be profiting the most from it.
Japatent Challenge
Dear DDJ,
This letter is directed to those Master Programmers who either believe they have successfully met every conceivable challenge, or that they can. I have one for you. I'll bet a steak dinner that no one in the world has or can do this one within the next six months. First one to successfully respond to my satisfaction gets the steak dinner--there'll only be one of those! But there may be alternate prizes for subsequent responses.
The challenge is Japanese patents; more specifically, putting a U.S. patent in a form such that it can be filed in the Japanese patent office in Tokyo with a reasonable hope of acceptance. It seems they still insist on the use of Japanese language characters, even though many technical terms are simply direct phonetic translations into Katakana or Hiragana characters. Maybe someday they will get around to permitting filings in English; until then, non-Japanese inventors are stuck with some very unpleasant facts: Either learn Japanese or use an expensive law firm if you want to have coverage in Japan. Those facts tend to shut out everyone but large corporations.
Proposed solution: A computer program that will translate from a U.S. patent on disk to produce a Japanese patent application on disk. I understand that Tokyo laws allow patent applications to be on floppy disk, as long as they are in proper format and in the Japanese language. The format itself does not appear to be much different from ours.
There are some formidable problems, such as accommodating the double-byte Kanji characters. Another is language syntax. Hey, if it requires a supercomputer, just say so; but I may ask for proof!
Partial or alternate solutions will be considered. Any takers?
Homer B. Tilton
Tucson, Arizona
Swap Scene
Dear DDJ,
Regarding Greg Renzelman's SWAP macro in the April 1992 "Letters" column, don't use it in an If, For, Do, or While clause, or strange bugs may occur. I do admire the clever use of the XOR operator, but the macro needs a bit of modification to work properly. To see what the problem is, consider Example 1(a) (the larger number goes in b), which expands to Example 1(b).
Only the a^=b; binds with the If; the b^=a; a^=b; is always executed. The solution is to rewrite the macro definition as in Example 1(c). And by the way, I wouldn't have noticed the bug either if I hadn't read about a similar case in Alan Holub's superb Compiler Design in C (Prentice Hall, 1990); it's on page 786, in case anyone wants to look it up.
Martin Bohme
Bensheim, Germany
Example 1
(a)
if (a>b)
SWAP (a,b)
(b)
if (a>b)
a^=b; b^=a; a^=b;
(c)
#define SWAP (a,b) (a^=b, b^=a, a^=b)
Dear DDJ,
Regarding C Language Q&A #36 (see "Letters," April and June 1992), it seems that most of the difficulty lies in the temporary variable; there is no obvious data type to use, and it is awkward to introduce a new scope arbitrarily in a program. If we could eliminate the need for a temporary variable, we should be able to do it.
Thinking back to a year or so ago, I recall having read an article which mentioned an old mainframe (IBM/360?) that provided a machine instruction that swapped two regions of memory using XOR. After reading the article, I began experimenting with the technique in C. I first came up with the following series of instructions for swapping two values:
a^=b; b^=a; a^=b;
Noticing that C allows me to express this more compactly, I came up with the following C macro: #define SWAP(a, b) (a^=b^=a^=b).
The beauty in using this technique is that the macro swaps two values without using a temporary variable! Of course, it is subject to the usual cautions about macros (e.g., don't say SWAP (++x,y)), and it only makes sense when sizeof(a)==sizeof(b).
For the skeptics, here is a proof that the macro actually works. The variable b is effectively set to b=b^a^b. Since XOR is associative and commutative, we can rewrite this as b=a^(b^b). Simplifying using the identities (x^x)=O and (x^O)=x, we get b=a^O=a. Similarly for a, we can write a=(a^b)^b^(a^b)=b^ (a^a)^(b^b)=b^O^O=b. (Note that we did not write a=a^b^(a^b) here--this would have been incorrect since the value of a changes early in the evaluation of the first macro at a^=b).
Bill Wilder
Needham, Massachusetts
_LETTERS_[LISTING ONE]
<a name="0179_0009">
void PatchSFT ( void )
{ char *sft,
*next_sft;
unsigned num_files;
int found;
// get first SFT block
_AH = 0x52;
geninterrupt ( 0x21 );
sft = * (char ** ) MK_FP ( _ES, _BX + 4 );
// searchthru till end of block chain
while ( sft != ( char * ) 0x0000ffff ) {
next_sft = * ( char ** ) sfrt;
// each block indicates the
// number of elements within
num_files = * ( int * ) ( sft + 4 );
sft += 6;
// search thru this block's
// elements looking for match
do {
found = strncmp ( drvptr + 10, sft + 32, 8 );
sft += _osmajor < 4 ? 53 : 59 ;
} while ( --num-files && found !+ 0 );
sft = next_sft;
}
if ( found == 0 ) {
( char ** ) ( sft + 7 ) = drvptr;
( unsigned * ) ( sft + 11) = FP_OFF ( drvptr );
}
}
<a name="0179_000a">
<a name="0179_000b">[LISTING TWO]<a name="0179_000b">
; as generated by SoundBlaster as a pulse width
; modulated signal on the internal IBM speaker,
VoiceTrkParms struc
dw 4 dup (?) ; pushed BP, ES and return address
StartOffset dw ? ; offset of address of voice track buffer
StartSegment dw ? ; segment address of voice track buffer
;StartOffset dw ? ; offset of address of voice track buffer
TrackLength dw ? ; Length of voice track
VoiceTrkParms ends
.model large
.code
public _VoiceTrk
_VoiceTrk proc far
push bp
push es
mov bp,sp
mov si,StartOffset[bp]
mov es,StartSegment[bp]
mov cx,TrackLength[bp]
in al,61h
push ax
mov ah,1Fh
and al,0FCh
out 61h,al
mov bp,0
cli
OuterLoop:
mov dh,0
mov dl,es:[si+bp]
test dl,ah
jz InnerLoop
or al,2
out 61h,al
InnerLoop:
cmp dl,dh
jne NoShutDown
and al0FCh
out 61h,al
NoShutDown:
inc dh
cmp dh,32
jne InnerLoop
inc bp
loop OuterLoop
sti
pop ax
out 61h,al
pop es
pop bp
retf
_VoiceTrk endp
end
Copyright © 1992, Dr. Dobb's Journal
