Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles - hp 1.2 08/01/83; site hp-pcd.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!pyramid!hplabs!hp-pcd!bill
From: bill@hp-pcd.UUCP (bill)
Newsgroups: net.micro.pc
Subject: Re: Re: How to slow down the AT (and the
Message-ID: <15200009@hpcvlo.UUCP>
Date: Tue, 28-Jan-86 13:58:00 EST
Article-I.D.: hpcvlo.15200009
Posted: Tue Jan 28 13:58:00 1986
Date-Received: Sun, 2-Feb-86 05:47:33 EST
References: <238@bnrmtv.UUCP>
Organization: Hewlett-Packard - Corvallis, OR
Lines: 17
Nf-ID: #R:bnrmtv:-23800:hpcvlo:15200009:000:801
Nf-From: hpcvlo!bill    Jan 28 10:58:00 1986


I wrote a program a while back that does effectively this same thing
(take over Timer Tick interrupt 1Ch and waste cycles), and noticed
a couple of things.  First, it's not a bad idea to do a far jump
to the old Int 1Ch handler after you've finished the delay.  This way,
you slow things down but still execute other code that has previously
taken over the interrupt (e.g., you can run this little program
multiple times to make things run slower and slower).  Second, it
doesn't work with a lot of programs for exactly that same reason:
they take over Int 1Ch for their own purposes, and never jump to the
old (i.e., your) handler when they're done doing their own thing.

Unfortunately, you can't do much about the second problem without
hacking up the application.

bill frolik
hplabs!hp-pcd!bill