djb@wjh12.harvard.edu (David J. Birnbaum) (05/03/90)
Tsrs that have to do something regularly usually do so by
hooking one of the two available timer interrupts: 8 and 1ch.
I understand that 8 gets called first, updates the system
clock, checks the diskette motor and turns it off when neces-
sary, and then issues int 1ch. After regaining control, int 8
issues the eoi command.
According to the Phoenix Technical Reference for the System
BIOS for IBM PC/XT/AT Computers and Compatibles, p. 430,
"The user can revector INT 1Ch to a user-supplied routine to
be executed on every system clock tick. No action is taken by
the BIOS when INT 1Ch is invoked unless this vector is modified
by the caller...."
Why do some programs hook int 8, while others hook int 1ch? Is
there any reason to favor one approach over the other for certain
applications? I understand that int 8 operates first, but unless
you plan to do something that depends on the reading of the system
clock before int 8 updates it, why would you need to get in that
early? I am particularly curious about how chosing one or the
approach would affect a screen blanking utility?
Thanks for any comments or suggestions,
David
============================================================
David J. Birnbaum djb@wjh12.harvard.edu [Internet]
djb@harvunxw.bitnet [Bitnet]
============================================================dixon@sagittarius.crd.ge.com (walt dixon) (05/04/90)
In a previous article David J. Birnbaum writes: [first two paragraphs deleted] >Why do some programs hook int 8, while others hook int 1ch? Is >there any reason to favor one approach over the other for certain >applications? I understand that int 8 operates first, but unless >you plan to do something that depends on the reading of the system >clock before int 8 updates it, why would you need to get in that >early? A while back I wrote a device driver to generate music on the PC (using a superset of the BASICA SOUND command). I needed a higher resolution timer interrupt than provided by the standard BIOS timer. I wound up reprogramming the timer to interrupt more frequently (by a factor of 16). Every 16th interrupt I called the old int 8 ISR. Relying on int 1Ch would have resulted in unwanted side effects. Walt Dixon {internet: dixon@crd.ge.com } {us mail: ge crd } { po box 8 } { schenectady, ny 12301 } {phone: 518-387-5798 } Walt Dixon dixon@crd.ge.com
mshiels@tmsoft.uucp (Michael A. Shiels) (05/05/90)
All of my utilities hook 8 and first call the old 8 then they sit in a semaphored section donig there stuff. This was because way back a lot of TSRs didn't chain to the old int 1C handler so all of a sudden you lost touch with timer ticks. Everyone passes 8 on or your machine would lose track of time.
rjlewis@miavx1.acs.muohio.edu (05/08/90)
In article <j45cvma7f@tmsoft.uucp>, mshiels@tmsoft.uucp (Michael A. Shiels) writes: > All of my utilities hook 8 and first call the old 8 then they sit > in a semaphored section donig there stuff. > > This was because way back a lot of TSRs didn't chain to the old int 1C handler > so all of a sudden you lost touch with timer ticks. Everyone passes 8 on > or your machine would lose track of time. I understand why you hook INT 8h, but how do you call the Original Int 8h handler, and have it RETURN to your code? If you call the original int 8h handler, it'll end with a IRET, and won't it bounce back to the currently executing program (and NOT your handler). -- __ Rich Lewis / ) / rjlewis@MIAVX1.acs.muohio.edu / __ __. _ /_ RL83SANU AT MIAMIU.BitNet (__/ / (_(_/\_/_)_/ /_
stever@Octopus.COM (Steve Resnick ) (05/10/90)
In article <1371.26461650@miavx1.acs.muohio.edu> you write: >In article <j45cvma7f@tmsoft.uucp>, mshiels@tmsoft.uucp (Michael A. Shiels) writes: > I understand why you hook INT 8h, but how do you call the Original Int 8h >handler, and have it RETURN to your code? If you call the original int 8h >handler, it'll end with a IRET, and won't it bounce back to the currently >executing program (and NOT your handler). Actually, if you CALL the old ISR it will IRET to some unknown region of memory because the IRET pops the first word on the stack (SS:SP) to the flags. The easiest way to call the old timer is to store the old ISR address in a DWORD. When you are ready to call the old ISR, push the flags, then do a far call to the ISR. When the ISR issues it's IRET instruction the 80n86 will pop flags, CS, IP and return to the next instruction after your call. Example: OLD08 LABEL DWORD ; This is the address used to call the OLD08OFF DW ? ; old int 08 ISR OLD08SEG DW ? NEWINT08H: PUSHF CALL DWORD PTR CS:[OLD08] <Do your processing here> IRET -------------------------------------------------------------------------------- Steve Resnick -<stever@octopus.COM apple!octopus!stever sun!vsi1!octopus!stever> 408/241-1533 Process Scientific, Inc. -------------------------------------------------------------------------------- "0x2B|~0x2B THAT is the question!" My views are my own and in no way represent the views of Octopus Enterprises or Process Scientific, Inc. -------------------------------------------------------------------------------- Flames, Grammar, and SPELLING errors etc: >/dev/null --------------------------------------------------------------------------------
wiml@blake.acs.washington.edu (William Lewis) (05/10/90)
In article <1371.26461650@miavx1.acs.muohio.edu> rjlewis@miavx1.acs.muohio.edu writes: > I understand why you hook INT 8h, but how do you call the Original Int 8h >handler, and have it RETURN to your code? If you call the original int 8h >handler, it'll end with a IRET, and won't it bounce back to the currently >executing program (and NOT your handler). No, although you have to call the old handler in a "special" way. An INT xx instruction does several things: Pushes the flags (PUSHF) Pushes the program counter (CS:IP) Fiddles with the flags a little bit (interrupt mask, etc.) Jumps to the handler routine All an IRET has to do is pop the old flags and the old CS:IP (and maybe reset an interrupt mask, I forget). So you can simulate an interrupt to any address by doing PUSHF CALL FAR addr and the IRET will return control to right after the CALL FAR instruction, as expected. -- JESUS SAVES | wiml@blake.acs.washington.edu Seattle, Washington but Clones 'R' Us makes backups! | 47 41' 15" N 122 42' 58" W