Re: Somewhat confused with Interrupts/TSRs

[Mike McCarty <Mike.McCarty@sbcglobal.net>]

John Coppens wrote:

Did you intend only to answer via private e-mail?

> On Fri, 30 Nov 2007 16:31:29 -0600
> Mike McCarty <Mike.McCarty@sbcglobal.net> 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!