From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike McCarty Subject: Re: Somewhat confused with Interrupts/TSRs Date: Fri, 30 Nov 2007 16:31:29 -0600 Message-ID: <47508F41.5070901@sbcglobal.net> References: <20071130151225.691a424b.john@jcoppens.com> <47505962.8060304@sbcglobal.net> <20071130175017.938b2cf5.john@jcoppens.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20071130175017.938b2cf5.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 to take this to private e-mail? > On Fri, 30 Nov 2007 12:41:38 -0600 > Mike McCarty 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!