yawei@bronze.ucs.indiana.edu (mr. yawei) (01/05/91)
I am not sure if I should advertise this, but in my opinion, the best place to do background processing is the BIOS buffered keyboard interrupt (Int 16H). Reasons: Timer interrupts (08h and 1Ch): they are the most consistent - occur once every 1/18.2 seconds. Disadvantage: system could be in very unstable conditions, such as you may be in the middle of a disk interrupt. If your handler is prepended, you can't stay on for long. Some people also claimed that TSRs that hooks to timer interrupts tend to steal a lot of CPU time unneccessarily (may or may not be true). If you must use the timer interrupts, appending to int 8 is preferrable than attaching to int 1Ch. Keyboard interrupt (09h): this only happens when a key is struck. System could also be in unstable conditions (for this reason, I don't recommend doing anything useful(!) in the background by hooking to any hardware generated interrupts). DOS Idle interrupt (28h): as many have pointed out, this only occurs when DOS is busy waiting for keyboard input. Moreover, if a TSR pops itself to the foreground using int 28h as the trigger (and subsequently uses int 16h to read keystrokes as many TSRs do), you don't get any more int 28h's even though the system is essentially in the same condition. Some TSRs popped up this way choose to simulate the condition by issuing int 28h's themselves, but simulated calls can't really be trusted here. What's so good about int 16h? - it's (almost) always there. Most of the time it is called even more frequently than the timer interrupts. It's called whether of not a key has been hit. The only times int 16h is inactive is when the foreground program is doing some CPU or disk-intensive stuff, at which point you probably really shouldn't be interrupting anyway; - the system is stable. Int 16h is a software interrupt, which means the foreground program is specifically requesting the interrupt, so it must be safely interruptable. In terms of DOS -- it should be in the same condition as int 28h, if the int 16h called was from DOS. - you can stay on relatively long -- just not too long to cause a significant delay in keyboard response for the user. You should still carefully check the DOS flags (InDOS flag and Critical Error flag) and maybe even the interrupt controller status. Someone could have carelessly issued an int 16h from inside a hardware interrupt (the same risk with simulated int 28h's). Comments/discussions are welcome. yawei p.s. Assembler programmer with 4+ yrs experience is looking for a job. I've been mostly writing TSRs and small utilities. I am looking for a part-time/contract job to get through school, and maybe a permanent job after me getting my MS degree. If you know of a position opening, do let me know. Thanks. (I am best at Assembler and C.)
david@csource.oz.au (david nugent) (01/05/91)
In <1991Jan5.043055.17637@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: > If you must use the timer interrupts, appending to int 8 is preferrable > than attaching to int 1Ch. How so? Using the timer (hardware) interrupt is guaranteed to cause problems where some previously installed TSR or device driver speeds up the timer rate. Normally such programs filter those to make any "higher level" timer handler receive control at the correct rate. Also, the PIC is rearmed by the time INT 1cH gets control, so you don't have to fiddle around with EOI's at all. It's an "ideal" place to pop-up. I've been using INT 1cH for a looong time without problems, so I just can't see why it's "preferrable", especially in a multitasking-under-DOS environment, like DESQview. I liked your suggestions re INT 16H though - they certainly have merrit. david
sonny@charybdis.harris-atd.com (Bob Davis) (01/05/91)
In article <1991Jan5.043055.17637@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: >I am not sure if I should advertise this, but in my opinion, the best >place to do background processing is the BIOS buffered keyboard >interrupt (Int 16H). Reasons: > [DELETIONS] >If you must use the timer interrupts, appending to int 8 is preferrable >than attaching to int 1Ch. > Could you please elaborate. Other things I have read (e.g. Dettmann's _DOS Programmer's Reference 2nd Edition_, page 417) recommend hooking to 1Ch in preference to 08. I confess that I do not understand a preference for EITHER over the other, since 1Ch is called by 08 and both block further hardware interrupts until done. >Keyboard interrupt (09h): this only happens when a key is struck. System >could also be in unstable conditions (for this reason, I don't recommend >doing anything useful(!) in the background by hooking to any hardware >generated interrupts). > Even if adequate safeguards against DOS re-entrancy are employed? Which you have to do - do you not? - even when hooked to INT16. [DELETIONS] >What's so good about int 16h? >- it's (almost) always there. Most of the time it is called even more > frequently than the timer interrupts. It's called whether of not a > key has been hit. The only times int 16h is inactive is when the Are you saying that DOS frequently calls this INT16 even though no INT09 (Key press hardware interrupt) has occurred? Why does it do that? > >You should still carefully check the DOS flags (InDOS flag and Critical >Error flag) and maybe even the interrupt controller status. Just as if you had triggered on INT09, for example? Doesn't this somewhat decreased the presumed advantage to hooking INT16? > Someone >could have carelessly issued an int 16h from inside a hardware >interrupt (the same risk with simulated int 28h's). > What is the bad thing about calling INT16 from inside a hardware interrupt handler? >Comments/discussions are welcome. > Thank you for your interesting posting. I stand to learn a great deal from it about the complex subject of background processing under DOS. _____________________________________________________________________________ Bob Davis, UofALA alum \\ INTERNET: sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\ UUCP: ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\ AETHER: K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\ VOICE: (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\ FAX: (407) 729-2537 | FOR MYSELF. |_________|
sonny@charybdis.harris-atd.com (Bob Davis) (01/06/91)
In article <773@csource.oz.au> david@csource.oz.au (david nugent) writes: >In <1991Jan5.043055.17637@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: > >> If you must use the timer interrupts, appending to int 8 is preferrable >> than attaching to int 1Ch. > >How so? > >Using the timer (hardware) interrupt is guaranteed to cause problems where >some previously installed TSR or device driver speeds up the timer rate. >Normally such programs filter those to make any "higher level" timer >handler receive control at the correct rate. > >Also, the PIC is rearmed by the time INT 1cH gets control, so you don't >have to fiddle around with EOI's at all. It's an "ideal" place to pop-up. Are you sure that the PIC is rearmed? I read that hardware interrupts are still locked out at the time that the 1Ch handler gets control, and that you can compromise things like interrupt-driven comm programs using the serial ports if you dawdle too long in EITHER an INT08 handler or in an INT1C handler. [Reference: Dettmann's _DOS Programmer's Reference, 2nd Ed._, p. 512] _____________________________________________________________________________ Bob Davis, UofALA alum \\ INTERNET: sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\ UUCP: ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\ AETHER: K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\ VOICE: (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\ FAX: (407) 729-2537 | FOR MYSELF. |_________|
yawei@bronze.ucs.indiana.edu (mr. yawei) (01/06/91)
In article <5187@trantor.harris-atd.com> sonny@trantor.harris-atd.com (Bob Davis) writes: >>If you must use the timer interrupts, appending to int 8 is preferrable >>than attaching to int 1Ch. > Could you please elaborate. Other things I have read (e.g. Dettmann's >_DOS Programmer's Reference 2nd Edition_, page 417) recommend hooking to >1Ch in preference to 08. Int 1Ch is not very consistent. In most machines, EOI is supposed to have been acknowledged when int 1Ch is called, but this is not universally true. Supposedly on some Compaq(?) machines, the EOI is acknowledged AFTER int 1Ch. Thus if you stay on thinking that EOI has already been acknowdged, the machine would hang. (I am not sure whether this is true for all Compaq machines. It was obviously a bug that could have been corrected. I can dig up the reference if neccessary.) Moreover, if you would ever trace through the int 8h and int 1Ch handlers of Sidekick (SK), you'd find something interesting. The int 8 handler has something at its beginning like: call cs:old_int_1C call cs:old_int_8 ... And its new int 1Ch handler is simply: iret This means even on a machine where you can normally expect EOI to have been ack'ed, it wouldn't be if SK is loaded after you. (Most of the problems with int 1Ch is with SK.) I have always taken it as a challenge to make my programs compatible with SK, but those guys are making it harder and harder. Maybe this is a dumb question, but is anyone out there still using SK? > I confess that I do not understand a preference >for EITHER over the other, since 1Ch is called by 08 and both block further >hardware interrupts until done. Not true. Hardware interrupts are blocked only when EOI hasn't been acknowledged (assuming that interrupt flag is enabled). >>Keyboard interrupt (09h): this only happens when a key is struck. System >>could also be in unstable conditions (for this reason, I don't recommend >>doing anything useful(!) in the background by hooking to any hardware >>generated interrupts). > Even if adequate safeguards against DOS re-entrancy are employed? >Which you have to do - do you not? - even when hooked to INT16. DOS re-entrancy is not the only consideration. It's the infinutely unpredictable nature of the hardware interrupts. It could happen when the disk head in the middle of writing something, or it could happen in the middle of a lower-priority hardware interrupt. You can check for most-likely problems, but you can't possibly check for everything. (I am beginning to sound like a mathmatician here, which I am not. :-) ) >>What's so good about int 16h? >>- it's (almost) always there. Most of the time it is called even more >> frequently than the timer interrupts. It's called whether of not a >> key has been hit. The only times int 16h is inactive is when the > Are you saying that DOS frequently calls this INT16 even though >no INT09 (Key press hardware interrupt) has occurred? Why does it do that? That's correct. Int 16h is not coupled to int 9 (unlike int 1Ch to int 8). Int 16h is an extension of the foreground software. Most programs spend most of their time repeatedly calling int 16h. They do this because they want to find out whether int 9 has placed any keystrokes in the buffer. :-) [Well, most programs actually call DOS, which in turn calls int 16h.] >>You should still carefully check the DOS flags (InDOS flag and Critical >>Error flag) and maybe even the interrupt controller status. > Just as if you had triggered on INT09, for example? Doesn't >this somewhat decreased the presumed advantage to hooking INT16? Cautionary steps should be taken however you do it, it's the likelihood of running into real problems that is different. >> Someone >>could have carelessly issued an int 16h from inside a hardware >>interrupt (the same risk with simulated int 28h's). > What is the bad thing about calling INT16 from inside a hardware >interrupt handler? I am saying that it's bad to pop up a window from inside a hardware interrupt, do some useful work, and maybe access int 16h and/or DOS disk services. If we agree to avoid this then there's not much reasons left to call int 16h from inside a hardware interrupt. I've written TSRs that are triggered by hardware signals. I simply let the hardware interrupt handler set a flag, and have the int 16h handler to check for this flag and then do the real work. I found this to be the best solution, especially on a system with a dozen TSRs loaded. yawei
yawei@bronze.ucs.indiana.edu (mr. yawei) (01/06/91)
In article <773@csource.oz.au> david@csource.oz.au (david nugent) writes: >Using the timer (hardware) interrupt is guaranteed to cause problems where >some previously installed TSR or device driver speeds up the timer rate. >Normally such programs filter those to make any "higher level" timer >handler receive control at the correct rate. Counter arguements - (1) most of the time you probably don't care the frequency int 8 is called anyhow; (2) BIOS assume that the frequency would be 18.2 and IT attaches to int 8. :-) But keep in mind that I was arguing AGAINST using the timer interrupts to do prolonged background processing, especially when such processing involves accessing the disks and other hardwares or interacting with the user. If you are writing a timer which only involves decrementing an internal counter, that's another story. >Also, the PIC is rearmed by the time INT 1cH gets control, so you don't >have to fiddle around with EOI's at all. It's an "ideal" place to pop-up. The part about EOI is not *quite* true, see my reply to an earlier article. On the other hand, if you APPEND (not PREPEND) to int 8, then the EOI is guaranteed to have been taken care of. >I've been using INT 1cH for a looong time without problems, so I just >can't see why it's "preferrable", especially in a multitasking-under-DOS >environment, like DESQview. Well, I've seen examples of int 1Ch having problems (incompatibility with SK, etc), but I've not seen an example of int 8 having problems. I'll be interested to know whether DESQview is having problem with TSRs using int 8. >I liked your suggestions re INT 16H though - they certainly have merrit. > david Thank you, yawei
david@csource.oz.au (david nugent) (01/06/91)
In <5188@trantor.harris-atd.com> sonny@charybdis.harris-atd.com (Bob Davis) writes: > >Also, the PIC is rearmed by the time INT 1cH gets control, so you don't > >have to fiddle around with EOI's at all. It's an "ideal" place to pop-up. > Are you sure that the PIC is rearmed? Whoops, did I say that? :-) You're quite right. The "correct" thing to do is to call the original INT 1cH handler, rarm the PIC with a specific EOI and enable interrupts. I actually found it was rearmed in some situations and others not. This is probably a function of BIOS versions, DOS versions and/or prior INT 1cH handlers. But I've never found a situation in which there's a problem with doing another specific EOI just in case. david
sonny@charybdis.harris-atd.com (Bob Davis) (01/06/91)
In article <1991Jan6.001935.25969@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: >In article <5187@trantor.harris-atd.com> sonny@trantor.harris-atd.com (Bob Davis) writes: The attributions for PRIOR posts are somewhat scrambled, so I indicate them. [yawei]: > >That's correct. Int 16h is not coupled to int 9 (unlike int 1Ch to int >8). Int 16h is an extension of the foreground software. Most programs >spend most of their time repeatedly calling int 16h. They do this >because they want to find out whether int 9 has placed any keystrokes in >the buffer. :-) [Well, most programs actually call DOS, which in turn >calls int 16h.] So, DOS does not, on its own, initiate the calling of INT16 -- a foreground program is actually doing it? The background task (a print spooler, for example) will simply stop being serviced if the foreground program terminates and a return to the DOS command prompt occurs while work yet remains for the background task, will it not? --- [yawei]: >>> Someone >>>could have carelessly issued an int 16h from inside a hardware >>>interrupt (the same risk with simulated int 28h's). [Davis]: >> What is the bad thing about calling INT16 from inside a hardware >>interrupt handler? [yawei]: > >I am saying that it's bad to pop up a window from inside a hardware >interrupt, do some useful work, and maybe access int 16h and/or DOS disk >services. If we agree to avoid this then there's not much reasons left >to call int 16h from inside a hardware interrupt. > I guess everytime you have said "hardware interrupt", I have thought of INT09, the keyboard hardware interrupt, and I believe now you must be thinking of things like serial ports and disk controllers. Certainly I agree that trying to tie background processing to serial port and disk controller interrupts sounds like a bad idea. But many TSRs pop-up and can do their useful processing inside the INT09 hardware interrupt handler. And some further call INT16, Function 2 from inside the INT09 hardware interrupt handler to look at the keyboard shift flags to determine if the hot-key has been pressed. Again, let me thank you for your interesting post and responses to my questions. And I do think your idea of hooking INT16 to provide service to a background task has a lot to recommend it. My major remaining concern is that the background task evidently stops being serviced if no foreground task uses INT16 to interact with the keyboard. _____________________________________________________________________________ Bob Davis, UofALA alum \\ INTERNET: sonny@trantor.harris-atd.com | _ _ | Harris Corporation, ESS \\ UUCP: ...!uunet!x102a!trantor!sonny |_| |_| | | Advanced Technology Dept.\\ AETHER: K4VNO |==============|_/\/\/\|_| PO Box 37, MS 3A/1912 \\ VOICE: (407) 727-5886 | I SPEAK ONLY | |_| |_| | Melbourne, FL 32902 \\ FAX: (407) 729-2537 | FOR MYSELF. |_________|
yawei@bronze.ucs.indiana.edu (mr. yawei) (01/06/91)
In article <774@csource.oz.au> david@csource.oz.au (david nugent) writes: > >I actually found it was rearmed in some situations and others not. This >is probably a function of BIOS versions, DOS versions and/or prior INT 1cH >handlers. But I've never found a situation in which there's a problem with >doing another specific EOI just in case. Doing an extra EOI is not a good idea. Yes, most of the time it probably doesn't show any ill effect, but suppose the timer interrupt comes on during another hardware interrupt, and you do an extra EOI... Worst yet, the timer interrupt has the highest priority, higher than hard disk, communication, etc., and can interrupt them all. Now we have a *potentially* serious consequence here. > david yawei
david@csource.oz.au (david nugent) (01/06/91)
In <1991Jan6.005549.29246@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: > In article <773@csource.oz.au> david@csource.oz.au (david nugent) writes: > >Using the timer (hardware) interrupt is guaranteed to cause problems where > >some previously installed TSR or device driver speeds up the timer rate. > >Normally such programs filter those to make any "higher level" timer > >handler receive control at the correct rate. > Counter arguements - (1) most of the time you probably don't care the > frequency int 8 is called anyhow; If you don't care, then it doesn't really matter. But then you can't use it as a "timekeeper". Secondly, because you're adding additional code, aka clock cycles to a timer interrupt cycle - especially if you've got a timer running at higher than standard speeds. Not, IMHO, a great way to go. > (2) BIOS assume that the frequency would be 18.2 and IT attaches > to int 8. :-) I can't see the counter argument here. If you intercept INT 08H and speed up the timer for any reason, then naturally you would attempt giving any previously installed handlers - including BIOS - ticks at the same rate. > But keep in mind that I was arguing AGAINST using the timer interrupts to > do prolonged background processing, especially when such processing > involves accessing the disks and other hardwares or interacting with the > user. If you are writing a timer which only involves decrementing an > internal counter, that's another story. Of course - no argument. Timer counters are most often used for timing, else you'd use INT 09H and set a flag on hot-key. > >Also, the PIC is rearmed by the time INT 1cH gets control, so you don't > >have to fiddle around with EOI's at all. It's an "ideal" place to pop-up. > The part about EOI is not *quite* true, see my reply to an earlier > article. On the other hand, if you APPEND (not PREPEND) to int 8, then > the EOI is guaranteed to have been taken care of. Yes, I posted a correction. It's not consistent. I haven't seen the same problems with the Compaq machines though. I'd be interested in any further information. Unlike INT 1cH, you can guarantee the PIC's state on returning from INT 8. But there's only the price of a few bytes in sending SEOI to the PIC before continuing. Normally I wouldn't do that unless the hot-key flag had been set and all is ok to "popup". > >I've been using INT 1cH for a looong time without problems, so I just > >can't see why it's "preferrable", especially in a multitasking-under-DOS > >environment, like DESQview. > Well, I've seen examples of int 1Ch having problems (incompatibility > with SK, etc), but I've not seen an example of int 8 having problems. > I'll be interested to know whether DESQview is having problem with TSRs > using int 8. DESQview has it's own scheduler and runs the PIC at a different rate. However, it does work around this problem by revectoring the PIC to another set of interrupts, and still generates INT 08H at the correct rate. Generally, there aren't too many problems. I guess they had to get it to work with SideKick too. :-) > >I liked your suggestions re INT 16H though - they certainly have merrit. Strangly enough, DESQview has problems with TSR's grabbing INT 16H. :-) The problem is that under DV there's a "common" INT 16H handler for all tasks. I've seen this really cause havoc, but after trying it and seeing the results, decided not to work out why since there were better and cleaner workarounds available. david
david@csource.oz.au (david nugent) (01/07/91)
In <1991Jan6.055747.7268@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: > >I actually found it was rearmed in some situations and others not. This > >is probably a function of BIOS versions, DOS versions and/or prior INT 1cH > >handlers. But I've never found a situation in which there's a problem with > >doing another specific EOI just in case. ^^^^^^^^^^^^ > Doing an extra EOI is not a good idea. Yes, most of the time it probably > doesn't show any ill effect, but suppose the timer interrupt comes on > during another hardware interrupt, and you do an extra EOI... ... which is why I said "specific EOI". > Worst yet, the timer interrupt has the highest priority, higher than > hard disk, communication, etc., and can interrupt them all. Now we have > a *potentially* serious consequence here. None at all. Regards, david
resnicks@netcom.UUCP (Steve Resnick) (01/08/91)
In article <1991Jan6.005549.29246@bronze.ucs.indiana.edu> yawei@bronze.ucs.indiana.edu (mr. yawei) writes: >In article <773@csource.oz.au> david@csource.oz.au (david nugent) writes: > >Well, I've seen examples of int 1Ch having problems (incompatibility >with SK, etc), but I've not seen an example of int 8 having problems. >I'll be interested to know whether DESQview is having problem with TSRs >using int 8. > [From Page 17-12 of the DESQview API Reference Manual, Version 1 (DESQview version 2.01)] : Hooking Interrupt 08H (the timer) The only hardware interrupt which generally has the enitre state of the task set up, and therefore has no restrictions on what its interrupt handler can do, is the timer interrupt. This is because DESQview gives the timer interrupt to the currently running process. Thus, if the user has set the foreground/ background slices to 9 and 3, then the foreground task will get nine consecutive timer interrupts while it is running, and each background task will get three consecutive timer ticks while it is running. This means that the entire task state is completely set up when it gets a timer interrupt. [DESQview Manual Stuff Done] So, what does this have to do with TSR's? Well, if your TSR is expecting a timer tick at a given rate consitently, forget it. It will not happen all the time. This, I expect goes for int 1CH as well, since it is usually called by the ISR for int 08H. There is a way around this, which is to load the TSR *before* DESQview, although that has its pitfalls as well. If your TSR hooks into int 09H, 10H, or 15H, you may not get your TSR to work correctly as DESQview uses these (and other) interrupts for its own work. (int 15H is the vector for DESQview's API, int 16H is hooked so DESQview can monitor video activity, and int 9 is used to monitor the keyboard). Most TSRs should run in a DESQview window, but be aware of the above limitations. Hope this helps, or was at least interesting ... ;) Cheers! Steve ------------------------------------------------------------------------------- resnicks@netcom.com, stever@octopus.com, steve.resnick@f105.n143.z1.FIDONET.ORG apple!camphq!105!steve.resnick, {apple|pyramid|vsi1}!octopus!stever - In real life: Steve Resnick. 530 Lawrence Expressway, Suite 374 Sunnyvale, Ca 94086 Flames, grammar and spelling errors >/dev/nul (This is a DOS machine =]) 0x2b |~ 0x2b, THAT is the question. -------------------------------------------------------------------------------
yawei@bronze.ucs.indiana.edu (mr. yawei) (01/08/91)
In article <20223@netcom.UUCP> resnicks@netcom.UUCP (Steve Resnick) writes: >[From Page 17-12 of the DESQview API Reference Manual, Version 1 (DESQview > version 2.01)] : >Hooking Interrupt 08H (the timer) >The only hardware interrupt which generally has the enitre state of the task >set up, and therefore has no restrictions on what its interrupt handler can >do, is the timer interrupt. This is because DESQview gives the timer interrupt >to the currently running process. Thus, if the user has set the foreground/ >background slices to 9 and 3, then the foreground task will get nine >consecutive timer interrupts while it is running, and each background task >will get three consecutive timer ticks while it is running. This means that >the entire task state is completely set up when it gets a timer interrupt. Thanks for the info. I wonder why DV does not, like David Nugent pointed out, filter the interrupt back to the correct rate? If you have an alarm clock running in one of these partitions, it's going to be 25% slower than normal. :-) It can, for example, call the routine twice for one in 3 ticks to do the compensation. The extra call needs to be caught at the bottom of the partition (with an 'iret') so that those loaded before DV still gets the correct rate. Btw, int 16h is the Bios keyboard, not video, interrupt. It seems some earlier versions of DV may not have int 16h routed properly. -- Just my guess, no slandering intended. :-) yawei
valley@uchicago (Doug Dougherty) (01/09/91)
yawei@bronze.ucs.indiana.edu (mr. yawei) writes: <Stuff deleted> >Btw, int 16h is the Bios keyboard, not video, interrupt. It seems some >earlier versions of DV may not have int 16h routed properly. -- Just my >guess, no slandering intended. :-) I find it interesting that 10 hex = 16 decimal and that 10H is video and 16H is keyboard. Kinda like it was designed to confuse people who are sure what RADIX they're programs are assembled under.