From: rock2000 AT ntplx DOT com (Rock)
Newsgroups: comp.os.msdos.djgpp
Subject: Re: Nasm and real-mode ISRs (bimodal)
Message-ID: <379e685d.1136020@news.ntplx.com>
References: <379739de DOT 5187825 AT news DOT ntplx DOT com> <37987832 DOT ADD AT erols DOT com> <379858cf DOT 153478 AT news DOT ntplx DOT com> <379CC355 DOT D47 AT erols DOT com>
X-Newsreader: Forte Free Agent 1.11/32.235
Lines: 153
Date: Wed, 28 Jul 1999 02:55:51 GMT
NNTP-Posting-Host: 204.213.189.29
X-Trace: news.ntplx.net 933173999 204.213.189.29 (Wed, 28 Jul 1999 10:59:59 EDT)
NNTP-Posting-Date: Wed, 28 Jul 1999 10:59:59 EDT
Organization: NETPLEX Internet Services - http://www.ntplx.net/
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

>> vectors.  I'm copyig the code into my DOS mem, for which I have a
>> segment and a 0 offset. I'm then using this segment:offset to set the
>> real-mode vector via the DPMI. Now since I've told the DPMI that the
>> offset is zero, shouldn't I get CS = segment and ip = 0 when my ISR
>> gets called?
>
>  Yes.
>
>> If the vector was set the way I told it, then cs SHOULD
>> be coming in pointing right to my routine/DOS mem.
>
>  Yes, but that doesn't mean what you think it means.
>
>  On entry to your ISR, IP is zero and CS is the segment to
>which you moved your ISR;  However, and use in your asm
>code of any of its own labels won't give a value relative
>to that segment.  Instead it will give a value relative to
>wherever your 16-bit code was originally loaded within the
>32-bit program (excepting "relative" jumps and calls which
>are "position independent").

But I'm not using any lobels in my real-mode ISR. I have a couple
jumps, which I assume are relative, but they're commented out now
anyways. The ISR gets the key and acks the interrupt (just in and out
instructions, no labels, and it works fine). Then it manipulates the
ax and bx registers to get the key 'index' in bx, and the key's on/off
status in ah. No labels there, and works fine up to this point. As
soon as I uncomment this instruction

mov [cs:(REAL_KEY_ISR_SIZE + 4 + bx)], ah

the program hangs. REAL_KEY_ISR_SIZE is the size I've set aside for
the actual real-mode ISR code (its actually about 70 bytes). The 4
we'll skip for now, its just another variable I'm using (but not
currently. That code is also commented out). And obviously bx has the
key index in it. From my understanding, this should be totally
relocatable. I've even tried moving cs into ds and using that (in
desperation), but still crashes.

>
>> >  One solution I do understand is to assemble your module
>> >through NASM twice:
>. . .
>> Yikes. Kind of lost me here. I'll put this on hold for now.
>
>  Sorry, to hear that, because the double assembly is
>probably the easiest solution.

Well, I never claimed to be smart. But if cs IS pointing to what it
should as we agree it is, then I don't see why there is a problem at
all.

>> My decision? Is there another way to do bi-modal interrupts without
>> copying the real-mode isr?
>
>  Not that I know of.  I guess you're right.  Either DJGPP or
>its documentation, or my understanding of it, is limited because
>it is not obvious how to create a "private" segment.  I was
>reacting mainly to your complaints about NASM.  I still don't think
>anything in the NASM design is making any aspect of this problem
>harder.

No, I guess that isn't where the problem lies if everything is
happening the way you've laid it out. Sorry, I say some stupid things
when I get frustrated, but luckily that hasn't been happening in
awhile (usually when I get frustrated I know its somehow my fault so I
don't get upset. In this case, I might be scapegoating since I can't
see any reason why, at a minimum, the real-mode ISR is failing. 

>
>> only reason I added the real-mode isr was because the program was
>> crashing without it from some RMCB. Now it still crashes, but with a
>> different problem. I think I know why, but don't how to fix it. Any
>> ideas?
>
>  First idea is that you don't need a real-mode isr at all.
>You just need to fix that bug in your protected mode isr (which
>is probably the register use bug you already identified).

Probably true, but now I want to get to it to work for personal
reasons. But i've found, from what it looks like, that if I just
install the protected mode ISR, then not only do I have a problem
getting my 'default' DS selector, but that even worse is if it is
called from real-mode, then just about all the selectors are illegal
real-mode segments  (except cs and, it looks like, gs). How can I get
all the information I need with just that?

>
>> My protected mode ISR is using data from the standard DS segment, as
>> well as data from low memory (i.e. my DOS memory). I'm loading es for
>> the DOS selector, and WAS assuming that DS always pointed to the
>> program's 'default' data section. But with DJGPP, that isn't true.
>
>  I doubt that it would be true in any DPMI system.

Under Watcom/DOS4GW it never changes any of the selectors (from what
I've seen). I guess that's an exception though. Watcom sets all the
selectors to a base address of 0 and length of 4 Gig. Everything is
accessable and no segment changes are ever done (I realize this loses
much of the protection, but its soooo much easier. Just my opinion).

>
>> it gets called. I guess I need to load ds with the default DS
>> selector, but how can I do that.
>
>  Re-ask just that question here (or search dejanews).  I don't
>remember the answer, but the question has been asked and answered
>here before.  (It might even be in the FAQ).

I'll try, I didn't see it in the faq, but I'll check again. Is there
any selectors that aren't used at all I could use to 'save' the needed
selectors in? I thought fs was unused, but something is setting it to
0 (of all numbers) in the program. GS seems to always point to the dos
low memory selector. Is it safe to always assume that it is untouched?

>
>> The nasm docs says that you never have to change selectors, especially
>> using DJGPP. Are they on drugs?!??!?!
>
>  If you were totally precise in any piece of documentation (covered
>every exception case) your documentation would all be impossible to
>understand.  What you read was written to support people writing
>subroutines to be called directly from C.  Writing interrupt service
>routines is a whole different activity and the normal rules don't
>apply.

OK, I'll admit that interrupts are probably special cases, so that's
not too bad (but it would nice to say that instead of saying *NEVER*
need to modify segment registers), but I can't say I like the way its
worded even in that respect. Even just calling from C, you can't
access DOS memory using the default DS selector, right? From my
understanding, the statement is still incorrect.

>  However, I think there is something in the FAQ about wrapper
>routines in the DJGPP library that handle all that for you.  If
>you use those rather than setting up the interrupt directly, you
>could even write the interrupt service routine in C.  If you can
>write it in C then you can also write it in NASM with all the
>register use assumptions in the NASM/DJGPP documentation.

I would rather avoid using any compiler specific stuff if possible. I
have it working under Watcom, which is going to be my real
environment, but wanted to port to DJGPP to make sure there weren't
any bugs since DJGPP is much stricter in both compilation and run-time
(I've found about 4 real bugs). But I want it to look as close to the
Watcom code as possible, and everything is done using DPMI calls. I'm
getting ready to give up at this point though. I know the bug is in
the keyboard ISR, and although I have a personal grudge now to get it
working in DHGPP, it won't help my original cause since the ISR works
fine under WATCOM.

Thanks
Rock