sonny@charybdis.harris-atd.com (Bob Davis) (11/13/90)
In what I read about designing TSRs, warnings are issued about monitoring the "InDOS" flag and/or "DOSOK" (Int28h) to determine when DOS function calls can safely be made. The impression is usually left on me that BIOS calls are OK without such monitorings. Is this true? Is BIOS reentrant? May I safely use ALL Interrupts below 20h without checking on ANY such flags or indicators in TSRs? Is it ONLY when I need to use Interrupts above 20h that the tedious checks to avoid re-entering DOS are necessary? Thanks. ______________________________________________________________________________ Bob Davis, UofALA'66 \\ 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. |_________|
Ralf.Brown@B.GP.CS.CMU.EDU (11/13/90)
In article <4844@trantor.harris-atd.com>, sonny@charybdis.harris-atd.com (Bob Davis) wrote: } May I safely use ALL Interrupts below 20h without checking } on ANY such flags or indicators in TSRs? INT 13h is non-reentrant due to the DMA controller and head-seek setup needed before a data transfer. The other BIOS calls are all pretty safe, though you may want to keep your own "busy" flags for them as well as INT 13h. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=- 412-268-3053 (school) -=- FAX: ask ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: 1:129/3.1 Disclaimer? | I was gratified to be able to answer promptly, and I did. What's that? | I said I didn't know. --Mark Twain
lsalomo@hubcap.clemson.edu (lsalomo) (11/13/90)
From article <4844@trantor.harris-atd.com>, by sonny@charybdis.harris-atd.com (Bob Davis): > > In what I read about designing TSRs, warnings are issued > about monitoring the "InDOS" flag and/or "DOSOK" (Int28h) to determine when > DOS function calls can safely be made. The impression is usually > left on me that BIOS calls are OK without such monitorings. > > Is this true? Is BIOS reentrant? > > May I safely use ALL Interrupts below 20h without checking > on ANY such flags or indicators in TSRs? > > Is it ONLY when I need to use Interrupts above 20h that the > tedious checks to avoid re-entering DOS are necessary? BIOS is not reentrant (OS/2 had to replace the BIOS routines because of this), but I do believe that you can use up to int 9 with no problems (someone else better verify this). Cheers, Q - the "Q"uestor for knowledge (, a degree, etc.) lsalomo@hubcap.clemson.edu ibmman@clemson.clemson.edu ============================================================================= "Gee Wally, I think there's something wrong with the Beaver." =============================================================================
2113av@gmuvax2.gmu.edu (John Porter) (11/14/90)
In article <11569@hubcap.clemson.edu> lsalomo@hubcap.clemson.edu (lsalomo) writes: >but I do believe that you can use up to int 9 with no problems (someone else >better verify this). YAHHH! What do you mean by "use" up to int 9? Those are interrupts are hardware-generated; you might program a handler for them, but you should never call them. The question is, what interrupts can you call while handling an interrupt. Many BIOS interrupts don't care how deeply you nest calls to them. Results may be unpredictable, but at least you won't snocker the system, unlike with many DOS calls. --jp # "Baby...Mother...Hospital...Scissors... # # "Creature...Judgment...Butcher...Engineer" OMD #
stever@Octopus.COM (Steve Resnick ) (11/15/90)
In article <2893@gmuvax2.gmu.edu> 2113av@gmuvax2.UUCP (John Porter) writes: >In article <11569@hubcap.clemson.edu> lsalomo@hubcap.clemson.edu (lsalomo) writes: >>but I do believe that you can use up to int 9 with no problems (someone else >>better verify this). > >YAHHH! What do you mean by "use" up to int 9? Those are interrupts are >hardware-generated; you might program a handler for them, but you should >never call them. The question is, what interrupts can you call while >handling an interrupt. Many BIOS interrupts don't care how deeply you >nest calls to them. Results may be unpredictable, but at least you won't >snocker the system, unlike with many DOS calls. >--jp With the exception of INT 05, all interrupts < 10H are hardware generated. Int 05 is generated by the int 9 ISR upon make/break of the print screen key. Calling hardware interrupts via software is generally not a good idea, since the ISR is expecting to diddle the 8259 PIC and maybe other hardware as well. Think, also, about what might happen if you call int 0EH (floppy interrupt) via software and a hardware floppy interrupt occurs? If the ISR didn't disable interrupts, and the 8259 puts a int 0eH on the bus, you may really mung your floppy... BTW - You can call int 5 (print screen) via software with no ill effects. -- Steve -- ---------------------------------------------------------------------------- steve.resnick@f105.n143.z1.FIDONET.ORG - or - apple!camphq!105!steve.resnick Flames, grammar errors, spelling errrors >/dev/nul The Asylum OS/2 BBS - (408)263-8017 IFNA 1:143/105.0
rcollins@altos86.Altos.COM (Robert Collins) (11/16/90)
In article <1990Nov14.210348.27367@Octopus.COM> stever@octopus.UUCP (Steve Resnick ) writes: > >With the exception of INT 05, all interrupts < 10H are hardware generated. >Int 05 is generated by the int 9 ISR upon make/break of the print screen key. >Calling hardware interrupts via software is generally not a good idea, since >the ISR is expecting to diddle the 8259 PIC and maybe other hardware as well. > There seems to be some serious confusion here. There are actually three types of interrupts: * CPU-generated interrupts * Hardware-generated interrupts * Software-generated interrupts Software-generated interrupts are, as we all (should) know, are INT n instructions. Hardware-generated interrupts are produced by hardware connected to the interrupt controller (like the 8259), which in turn yank on the INT line of the CPU. By programming the 8259, these interrupts can occur anywhere in the interrupt range, on 8-byte boundies (even starting at 0). IBM, in their infinite wisdom chose to ignore Intel's warnings not to put hardware-generated interrupts below 20h, and IBM put them (the first 8) starting at 8. This clearly overlaps with CPU-generated interrupts on the '286, '386, and '486. At the end of a hardware interrupt routine, you must send an End Of Interrupt (EOI) to the Programmable Interrupt Controller (PIC). CPU-generated interrupts are, as their name implies, generated by the CPU; like invalid opcode, or stack fault. Intel reserved the first 20h interrupts for CPU-generated interrupts. Currently (80486), the first 17 (11h) are used. The termination of these interrupts don't require writing an EOI to the PIC. >Think, also, about what might happen if you call int 0EH (floppy interrupt) >via software and a hardware floppy interrupt occurs? If the ISR didn't >disable interrupts, and the 8259 puts a int 0eH on the bus, you may really >mung your floppy... When a hardware-generated interrupt occurs, upon entrance to the ISR, interrupts are disabled. The ISR doesn't need to disable interrupts, it is done automatically by the CPU. This statement is not intended to contradict the validity of any of the points I am responding to, I'm just trying to clarify how this stuff works. It's true, there is NEVER a valid reason to call a CPU, or hardware- generated interrupt. However, for the BIOS, this is a different story. Remember on the XT, the coprocessor ERROR was routed through NMI. So, IRQ9 (by memory, so don't quote me) must call INT2 to remain compatibility with programs and hardware that assumes it's running on an XT. -- "Worship the Lord your God, and serve him only." Mat. 4:10 Robert Collins UUCP: ...!sun!altos86!rcollins HOME: (408) 225-8002 WORK: (408) 432-6200 x4356
2113av@gmuvax2.gmu.edu (John Porter) (11/18/90)
In article <1990Nov14.210348.27367@Octopus.COM> stever@octopus.UUCP (Steve Resnick ) writes: >With the exception of INT 05, all interrupts < 10H are hardware generated. >You can call int 5 (print screen) via software with no ill effects. Yeah, I know. I didn't feel it necesary to go into these bizarre exceptions. I also didn't mean "never" in an absolute sense. Calling int 5 is actually kinda fun. Trapping it is even more fun. --jp # "I wish I was in Tiajuana, eating barbecued iguana." # "The moon is beautiful. The sun is even more beautiful."