janices@tekig5.UUCP (Janice Singer) (05/04/85)
Help once again! I have three questions. 1) What does DOS do when you try to execute one of it's interrupts? Can a user-defined interrupt-handler call a DOS Function. What about the BIOS interrupts. Can I redefine a BIOS interrupt so that it will call a DOS Function. We have a theory that each time a DOS interrupt is called, DOS does some "magic" and then passes control to the handler. We think this "magic" is some sort of lock on its own functions, thereby prohibiting a user-defined interrupt-handler from calling DOS functions. 2)Can I get a listing of DOS somewhere. 3)Where can I find answers to these types of questions. For those who have seen my questions before, please excuse the reposting. Please reply by mail, With enough interest, I will post summary to the net. THANKS, JANICE SINGER arpa: tekig5!janices@tektronix csnet: janices%tekig5@tektronix uucp: !tektronix!tekig5!janices
jp@lanl.ARPA (05/05/85)
I have a related query. I am attempting to convert a PC DOS program to run under MS DOS. The program crashes when I try to run it without any changes. Using debug I found that the point at which it died was an INT 16H. Further searching led to the discovery that INT's 10, 14, 16, and 17 are used. I have learned that 16 is Video I/O, 14 involves communications (serial ports??), 16 refers to keyboard input, and 17 refers to the printer. I don't believe the program uses any graphics or BASIC functions. I am not sure if it writes directly to the video RAM. Can anyone tell me more about these INT's and if I can patch corresponding DOS function calls at the interrupt locations to fix the program so it will run under MS DOS?? Thanks, Jim Potter jp@lanl.arpa
tsc2597@acf4.UUCP (Sam Chin) (05/06/85)
<>
In response to the queries about how to use the interrupt capabilities on
the PC and the conversion of PC specific programs to generic MS-DOS
programs, I am writing a few lines which I hope will be of help.
On the PC or any other 8086/88 based machine, the interrupt vectors are
stored in the first 1K of low memory. Each address is a 16 bit segment and a
16 bit offset giving 4 bytes in total. You can therefore have 256 interrupt
vectors. If you want to examine memory, just use the D option in DEBUG. When
the PC starts up, a program in the ROM BIOS initializes the interrupt
vectors 2,5,8,9,E, 10-1A, 1C-1F. They are:
2 - Non-Maskable
5 - Print Screen
8 - 8253 System timer
9 - Keyboard (Raw keyboard interrupt - when a key is pressed this goes
off)
E - Diskette (Raw diskette interrupt)
10 - Video control for monochrome and CG adapters
11 - Reads Switches on Motherboard
12 - Gets memory size from switches
13 - Diskette I/O (Most people use this one as E is a system interrupt)
14 - Communications - Serial I/O
15 - Cassette I/O
16 - Keyboard I/O (This too is used rather than interrupt 9)
17 - Printer
18 - Cassette BASIC
19 - Power on reset
1A - Time of Day
1C - Timer Tick
1D - Video Init
1E - Diskette Parameters
1F - Graphics character extension
Interrupts 0 to 7 are 8088 Interrupt Vectors, Interrupts 8 to F are
multiplexed to the 8088 through the 8259 interrupt controller which
prioritzes the interrupts, Interrupts 10 to 1A are entry points into the
BIOS, 1B and 1C user supplied routines and 1D to 1F BIOS parameters. After
the BIOS initializes all the interrupt vectors, it reads the boot track on
the floppy or hard disk and the boot program takes over, loading MS-DOS and
its associated higher level device drivers.
A program is not a generic MS-DOS program if it uses any of the above
interrupts or attempts to control various chips in the PC through the 8088
ports or attempts to access/modify video memory. Most PC Clones such as
COMPAQ, Corona etc are completely bios compatible (the above interrupts are
implemented) but may not be totally hardware compatible (the chips used to
build it are different or at different locations) On machines such as the
DEC Rainbow, Zenith Z-100 or my Lomas S-100 system, interrupts 0 through 1F
are used for totally different things and none of the hardware is at the
same locations as the PC. Therefore, only generic MS-DOS programs will run
on it. A program is generic MS-DOS if and only if it uses only interrupts
20H through 3FH.
MS-DOS reserves interrupt types 20H to 3FH of which only 20H to 27H are
implemented (as of DOS 2.0). The rest are reserved for future use. Of the
interrupts 20H to 27H, the one of most interest is interrupt 21H. This
interrupt controls I/O to various devices, the file system, memory
allocation etc. The particular function is controled by putting a function
number in the AH register prior to issuing the interrupt.
Programs which use BIOS interrupts are much easier to convert to generic
MS-DOS than programs which access the hardware directly. To convert
programs, replace the interrupts 0 to 1F that you find in your program with
the same actions using interrupt 21H and the appropriate function. As a
simple example, the video interrupt (10H) on the PC will clear the screen if
you put 6 in register AH and 0 in register AL. To simulate this on a Z-100,
you would invoke interrupt 21H with function 2 (display a character) twice.
The first time you would put 1BH in DL and the second time put 'E' in DL.
This outputs the escape sequence <ESC>E to the Z-100 which causes the
firmware in the terminal to clear the screen. It may not be easy to simulate
some of the interrupts but certainly, the video interrupt (10H) and the
keyboard interrupt (16H) etc can be simulated.
Finally, the following references will be useful.
(1) IBM PC Technical Reference Manual
(2) MS-DOS Programmers Manual (I'm not sure of the exact title but this is
not the DOS 2.0 manual)
(3) Assembly Language Programming for the IBM PC by David Bradley (talks
a lot about the hardware on the PC)
(4) IBM PC & XT Assembly Language by Leo Scanlon (Has a nice section which
completely details the interrupts)
Good Luck!
Sam Chin
UUCP: allegra!cmcl2!acf4!tsc2597
ARPA: tsc2597.acf4@nyulisa@phs.UUCP (Jeffrey William Gillette) (05/07/85)
[]
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 Universitytsc2597@acf4.UUCP (Sam Chin) (05/09/85)
<> >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. I'm not sure if the extended code is returned in the ah register but the standard way to read an extended code is to issue the read (function 1,6,7 or 8) again if the first result is 0. ie. if (0 == (c = getchar())) extended_code = getchar(); This is documented in the DOS 2.0 reference manual Appendix D-17 bottom note. Sam Chin allegra!cmcl2!acf4!tsc2597 tsc2597.acf4@nyu
indra@utai.UUCP (Indra Laksono) (05/10/85)
> > 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. > > > Jeffrey William Gillette ...!duke!phs!lisa > Duke University The idea to write an interrupt handler is a good one, the one to use another interrupt number is bad, there is no reason why you can't use INT 10H. The INT10H are all video functions anyway, so there is a very good chance that your program will use most, if not all of them. If you did implement the COMPLETE INT 10H in another routine, this patch will work for other programs that need INT 10H as well, not just one. It will probably help if you do : A>DEBUG -D0:40 ; 10H * 4 = 40H 0000:0040 XX YY AA BB -UBBAA:YYXX BBAA:YYXX ; The routine in the bios ......... If you redirect your output to the printer, you can study it in your leisure and optimize it yourself. I know because I have tried something similar on my sanyo 555 [vb].
tsc2597@acf4.UUCP (Sam Chin) (05/13/85)
<> On some machines, it is *necessary* to use an interrupt other than 10h. The simple reason being that interrupt 10h is already used in that machine for some function such as controlling the disk controller etc. Since the device drivers for operating systems which run on the machine expect to be able to use 10h for functions other than handling the video interrupt, it would be deadly to use 10h. Sam Chin allegra!cmcl2!acf4!tsc2597 tsc2597.acf4@nyu.ARPA