home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!sun-barr!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!usenet.coe.montana.edu!news.u.washington.edu!ogicse!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!ralf
- From: ralf+@cs.cmu.edu (Ralf Brown)
- Newsgroups: comp.os.msdos.programmer
- Subject: Re: int 9h
- Message-ID: <BuHn1n.Kwq.2@cs.cmu.edu>
- Date: 12 Sep 92 23:10:33 GMT
- Article-I.D.: cs.BuHn1n.Kwq.2
- References: <DAVIS.92Sep11115609@pacific.mps.ohio-state.edu> <18t26lINN3jm@darkstar.UCSC.EDU>
- Sender: news@cs.cmu.edu (Usenet News System)
- Organization: School of Computer Science, Carnegie Mellon
- Lines: 17
- Nntp-Posting-Host: b.gp.cs.cmu.edu
-
- In article <18t26lINN3jm@darkstar.UCSC.EDU> noesis@ucscb.UCSC.EDU (95016000) writes:
- }at the end of your interrupt you need an 'out 20h, 20h' or your machine will
- }lock.
-
- But only if you DON'T chain to the original INT 9 handler. The original
- handler will issue that OUT (it tells that interrupt controller that the
- highest-priority pending interrupt has been handled). If you issue it
- again, it is possible that a lower-priority interrupt (i.e. anything but a
- timer tick) which has occurred while INT 9 was being handled will be lost.
- For that reason, it is preferable that you issue an OUT 20h,61h instead
- (this says that IRQ1 has been handled).
-
- --
- Internet: RALF+@CS.CMU.EDU |The University would disclaim this if it knew...
- FIDO: Ralf Brown 1:129/26.1 |
- BIT: RALF%CS.CMU.EDU@CARNEGIE|"Success has a simple formula: do your best,
- AT&Tnet: (412)268-3053 school| and people may like it." -- Sam Ewing
-