Re: Somewhat confused with Interrupts/TSRs

Mike McCarty
2007-11-30T22:31:29Z

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