Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1 6/24/83; site phs.UUCP Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!duke!phs!lisa From: lisa@phs.UUCP (Jeffrey William Gillette) Newsgroups: net.micro.pc Subject: Re: Questions on Interrupts and DOS Message-ID: <1028@phs.UUCP> Date: Mon, 6-May-85 22:57:02 EDT Article-I.D.: phs.1028 Posted: Mon May 6 22:57:02 1985 Date-Received: Thu, 9-May-85 01:55:28 EDT Organization: Duke Physiology Lines: 57 [] Let me add a few observations to the helpful comments others have made. 1. Regarding interrupt 10h (crt output), the simple solution is to route all output through MS-Dos function call 2 (display character), or 6 (direct console i/o). However, this will probably be thoroughly unsatisfactory for video intensive applications (like word processors). For many of these programs almost 1/2 the calls to int 10h are to position the cursor. The overhead of sending escape sequences through DOS (5 bytes apiece in the ansi standard) will turn your favorite PC wunder-program into an excuse for homicide. This is especially true if your MS-Dos machine already has a poorly written bios (as does my Victor 9000 - I guess Victor couldn't afford to hire assembly language programmers, 'cause my copy of the bios source is written in PL/I). The only really satisfactory solution for video intensive programs is to write your own custom interrupt routine and patch it into the interrupt dispatch table through Dos function call 25h. Note that even if your machine has reserved interrupt 10h for some other purpose, you can pick some other (unused) interrupt. Simply take debug, find all instances of the int 10h instruction (s cs:0 f000 cd 10), and replace the 10 with your new interrupt number. 2. Regarding interrupt 16h (keyboard input), there may be a good deal more here than is at first apparent. The easy solution, route a call through Dos call 7 (direct console input), or call 6 (direct console i/o - status) will only return ascii codes. IBM's int 16h returns both the ascii value and the scan code for the key pressed. It is this latter code that enables a program to distinguish, e.g., the '+' on the top row from the '+' on the keypad, and the various numbers. In addition, all the function keys, the unshifted keypad keys, and alt-key combinations return an ascii value of 0. Their interpretation depends exclusively upon the "extended" code returned in the ah register (in place of their scan code). Thus, the only way to handle programs that have special bells and whistles bound to specific PC keys is to create a translate table that will take the output of your Dos 7/6 calls and construct an IBM { scan code | extended code }, ascii value result. A footnote to the keyboard problem. The value returned from int 16h when the grey '+' is pressed (4e2b) is identical whether the key is shifted or not. PC-Write (for one) performs different functions when the key is shifted. Evidently it makes copious use of the shift status flag (also available from int 16h). For programs like PC-Write, it may be necessary, not only to keep track of the status of shift locks, but also to update a shift flag for every key pressed! While I have had some success porting PC programs to other MS-Dos machines (notably my Victor) by simulating PC interrupts, this is definitely the hard way to get the job done. But a word of encouragement - by taking on this type of project you will learn many wonderful and terrifying secrets about MS-Dos and about your machine's innermost workings available in no other way. Jeffrey William Gillette ...!duke!phs!lisa Duke University