From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike McCarty Subject: Re: Somewhat confused with Interrupts/TSRs Date: Mon, 03 Dec 2007 11:00:02 -0600 Message-ID: <47543612.1000808@sbcglobal.net> References: <20071130151225.691a424b.john@jcoppens.com> <47505962.8060304@sbcglobal.net> <20071130175017.938b2cf5.john@jcoppens.com> <47508F41.5070901@sbcglobal.net> <20071130211248.ae41594a.john@jcoppens.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20071130211248.ae41594a.john@jcoppens.com> Sender: linux-msdos-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: FreeDOS John Coppens wrote: Did you intend only to answer via private e-mail? > On Fri, 30 Nov 2007 16:31:29 -0600 > Mike McCarty wrote: > > >> I take issue with your statement that INT 1CH is optional. As I stated >> before, it is the system clock interrupt (software level). INT 28 is >> DOS_IDLE as you stated. But even if DOS_IDLE is not being called, >> INT 1C should be. > > I stand corrected, Mike... I _did_ read that somewhere, but now I I didn't mean to be "in your face". Sorry it sounded that way. > disassembled the short code of Int08, and Int1C is called _there_, at > the end. So, unless interrupts are disabled, the TSR should be called > (which isn't happening). I'll investigate along that path. Right... INT 08H is the hardware clock. All the INT 08H handler should do really is keep the hardware happy and ready to make another timer tick, and then pass things along to the software timer system, by using the system timer interrupt INT 1CH, which is the software level clock. INT 1CH keeps the TOD etc. It is not optional. One should not hook INT 08H as it needs immediate access to the hardware. If one wants to mess with the system timer I/F and then pass back after having done some other work, one should hook INT 1CH. > <...> >>> And at F000:C016 is a HLT. I suspect this is part of the mechanism >>> dosemu uses to emulate. >> Ah. Interesting. Perhaps the HLT instruction is mis-emulated! >> It should halt until an interrupt occurs, then exit. It appears >> that the hardware clock interrupts are not being passed through >> to the emulation level to cause the HLT to exit. > > Privately, James confirmed that the HLT instruction is used by DOSemu to > emulate the BIOS functions (that's why the BIOS is so small - my $.02) Not surprising. This looks like an unintended consequence. INT 08H is tied to a physical interrupt line controlled by the PIC. When the HLT instruction is executed with interrupts disabled, it exits the halted state when an interrupt occurs. http://library.n0i.net/hardware/i8086opcodes/#HLT >> Another possibility is to patch the program using CRT to use >> the corresponding MSDOS call INT 21H service 08H to read a >> character w/o echo. This opens you up to ^C and ^BREAK messing >> you up, however. Do you already trap those? You'd need an >> INT 23H handler. > > Yes, I do... > > I think it boils down to the fact that for some reason Interrupts seem to > be disabled while Int16 is called, else the TSR would be called as it That particular bit of code needs to be interrupt protected, I suspect. The issue is this: two bits of code are using/modifying the same variables. The keyboard interrupt handler (the one which responds to the physical interrupt line associated with the 8048 programmed as the keyboard interface processor) places characters into the BIOS TA buffer. It looks at head and tail, and if there is room it puts a character in, otherwise it sets up the sound system to make a "beep". It also modifies the head pointer in the BIOS area when it puts a character into the TA buffer. The INT 16H handler should look at tail and head, and use this to ascertain whether the TA buffer be holding anything. If TA is holding, then the INT 16H handler should take the character at tail, and update tail. If it makes a decision that it does not have a character available, then it needs to wait. It does this by executing HLT. When a hardware interrupt occurs, then the processor exits halted state. Without interrupts being disabled, a race state would occur. The INT 16H code would check, and see that no character is available, making a decision to halt. If, before the HLT instruction is executed, the keyboard interrupt occurs, then the character gets placed into the TA buffer, and the interrupt event is now over. When the processor later executes the HLT, then the keyboard event would already be past. > should be. This may be a problem resulting from how things are simulated > in DOSemu, in which case the whole thing may actually work on the DOS > machine, ;-) It looks to me like some at least of the emulated hardware interrupt events are not getting passed up the emulation chain to the HLT pending halt state to cause it to exit. I haven't read the code, just guessing from the behavior. > I'll test that tomorrow... Thanks for all the hints! Quite welcome! > > John > > -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} Oppose globalization and One World Governments like the UN. This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that!