On Fri, 30 Nov 2007 12:41:38 -0600
Mike McCarty <Mike.McCarty@xxxxxxxxxxxxx> wrote:
> John Coppens wrote:
> > Hello people.
> >
> > I accepted the task of trying to get a very old datalogging program
> > working for a friend. It is needed to read an older sensor, and
> > apparently no other software is available.
> >
> > It's a bit large (170 kB exe) to disassemble completely, but cursory
> > investigation shows it was written in Turbo Pascal. Apparently the CRT
> > unit was included, which makes executable use internal keyboard access
> > instead of MsDOS functions.
> >
> > 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).
> > 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.
> > 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
F800:6832 7405 JZ 6839
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.
> > Does anyone know of this (TSR) problem or can anyone suggest a
> > solution?
>
> You could try stuffing the BIOS type-ahead buffer. Is there a reason
> you don't have source? Also, ISTM that you may have uncovered
> an incompatibility. Are you running actual MSDOS, or freedos?
> You might try running actual MSDOS rather than freedos, still
> using dosemu.
That's what I'm doing in the TSR. And works fine, too. With other
programs or Pascal programs without CRT compiled in. But it stops working
with any Pascal program with CRT. Eg.:
program Simple;
uses
CRT;
var
w: string;
begin
readln(w);
writeln('I''ve read:', w);
end.
It seems that's because, with CRT, the program uses Int16 to read
characters, which means DOS can't activate either Ints 1Ch or 28h (and
thus the TSR remains unable to stuff keys). I'm guessing this would be
exactly the same with MsDOS instead of FreeDOS.
Hope this clears it up...
John
-
To unsubscribe from this list: send the line "unsubscribe linux-msdos" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
