Re: Somewhat confused with Interrupts/TSRs

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

John Coppens wrote:

Did you intend to take this to private e-mail?

> On Fri, 30 Nov 2007 12:41:38 -0600
> Mike McCarty <Mike.McCarty@sbcglobal.net> wrote:
> 
>> John Coppens wrote:
>>> Hello people.

[snip]

>>> All this is important, because I want to simulate keypresses and the
>>> TSR doesn't seem to work with any CRT using Pascal program.
>> I don't understand this statement. Do you mean that there is another
>> TP program which uses the CRT module and which must run with this
>> TSR, but does not?
> 
> Hi Mike. Sorry for all the confusion. It's the TSR that has to generate
> the keypresses, and the TSR works fine. Eg. I can call 'debug', send a
> dump command, and exit again, all via the TSR.
> 
> The sensor logger is the one that seems to be compiled with 'uses CRT' in
> Pascal, which means that the executable uses Int16 instead of the DOS
> routines to read the keyboard (and to write the screen).

Ah, I see. So, the TSR is stuffing the BIOS TA buffer, but you aren't
able to get it from the *other* program. AIUI the TSR isn't running
because the DOS IDLE interrupts aren't being used. This is, as you say,
because you use the BIOS keyboard interrupts.

>>> I followed the program to be using Int16 for key input, which probably
>>> explains why no Int28 or Int1C calls are made anymore (needed for the
>>> TSR to work)...
>> I also don't follow this. The Int16 BIOS calls don't disturb the
>> clock interrupts, AFAIK. I've used them many times.
> 
> Yes... The logger calls Int16, which works fine, except that in that case
> the TSR stops working, because both 'hooks' to 'stimulate' the TSR (Int
> 1C and 28) stop working (see below). Note that both 1Ch and 28h are
> 'voluntary' interrupts, called only when DOS is idle. So while in the
> (BIOS's) Int16, DOS won't be able to call them.

Which INT16 services are you using? [grabs old MSDOS programming book]
Service 00H	Wait until a characer is ready for input, put into AL
         01H	Read status, return flag and char if one ready
         02H	Return keyboard flags

Ok, I guess you're calling service 00H, and it is "hang and wait".

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 tried to follow where 16h goes to, but, using debug in DOSemu, this
>>> leads to a HLT instruction...
>> Sounds like the TSR may be trying to guard itself against debug. I wrote
>> some device drivers 'way back on contract, and the people I worked
>> for wanted to prevent them from running when debug was being used.
> 
> No. It's not the TSR. Run xdosemu, and then debug (no TSR running). The
> 16h interrupt vector points to F800:682E. At that address is a very
> simple routine:
> 
> F800:682E FB            STI
> F800:682F F6C4EF        TEST    AH,EF

This code looks for an extended keyboard service.

> F800:6832 7405          JZ      6839

We get here for all "normal" services, except service 00H.
So, services 00H and 10H wind up here. 00H is read keyboard.

> F800:6834 EA16C000F0    JMP     F000:C016
> F800:6839 9C            PUSHF
> F800:683A 9A16C000F0    CALL    F000:C016
> F800:683F 74F8          JZ      6839
> F800:6841 CF            IRET
> 
> 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. As a NASTY work
around, you could patch out the STI instruction. This leaves
you with a window during which the code might hang, due to the
keyboard interrupt arriving just before the HLT. If the clock
interrupt eventually does get passed through, then it would
eventually recover. You could do this in a little program which
runs just before the TSR gets run (and installs itself) during boot.
Hopefully, this area is not in emulated ROM, prohibiting writes.
If it is, then you could copy the entire BIOS INT 16H routine
into ANOTHER TSR which then omits the STI, and revector
to that.

Another possibility is to patch the program using CRT to use
service 01H in a loop until it finds "character ready" and then
use service 00H to read it, which hopefully then doesn't enter
this code. Or put that into another TSR (as above) which emulates
service 00H by using 01H until it gets "ready" and then use
00H to read it and return. This may be the best way, as it has
very little interaction with other programs, and is less "fiddly".
This little TSR could be just a few bytes long, actually. The
code would look like this:

	resize memory END_MEM
	disable interrupts
	save old INT 16H vector
	set self as new INT 16H handler
	enable interrupts
	TSR

handler:
	if service is not 00H
		jump to old INT 16H vector
loop:
	load AH with 01H
	push flags to emulate interrupt
	call old INT 16H vector
	if flag indicates not ready
		jmp to loop
	load AH with 00H
	push flags to emulate interrupt
	call old INT 16H vector
	IRET
END_MEM:

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.

[...]

> Hope this clears it up...

I think I've got a better handle. This looks like an oversight
in dosemu which causes an interaction when used with the INT 16H
BIOS keyboard interrupt service.

http://www.ctyme.com/intr/int-16.htm

Your best bet may be the little TSR I described above.

Mike
-- 
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!