Mail Archives: djgpp/1999/07/24/09:10:35
>>
>> I'm trying to setup a bimodal ISR for the keyboard handler and I'm
>> having big problems under DJGPP (CWSDPMI).
>. . .
>> My problem is with NASM. I can't seem to find a way to write the
>> real-mode ISR in a way that allows the routine to index the key table.
>> In other assemblers, I could use "ASSUME cs" to tell the assembler
>> that I want cs to point to my function and then simply index the table
>> as cs:[128 + keyIndex]. However, NASM doesn't support ASSUME,
>
> True, but ASSUME does nothing useful in this context. ASSUME
>in a normal assembler would not do anything to make cs point to
>your function. It would allow you to leave off the cs: and have
>the assembler figure out that it must add the cs: in for you. I
>don't think you want that. I think explicit cs: (where required)
>makes an ISR much clearer then letting the assembler figure it
>out.
Heh, I guess I don't know what ASSUME does. I was searching for an
explanation why the routine was failing. (Now that I looked ASSUME up,
it really stinks. I'm glad NASM doesn't use it).
> Possibly you are having a syntax problem. NASM requires the
>cs: on the inside of the []. so you index the tables as
>[cs:128 + keyIndex]
No, I got this one earlier on (1 thing I did right anyway)
>> apparently cs is not coming in pointing directly to my routine.
>
> That isn't a issue of the assembler at all, it is an issue
>of the linker and of the way that you copy the routine to low
>memory and set up its vector.
>
> You are probably copying the code from an offset in the
>32-bit segment to fixed offset zero in an allocated low memory
>segment. Any offsets within the asm code would be resolved
>by the linker to values relative to the entire segment in
>which it is linked. Then you expect it to run after you have
>moved it so that those offsets need to be relative to the
>start of the function. There are several solutions to the
>problem, but I don't know enough about the LD linker for most
>of them.
Yeah, moving the code is going to burn me I guess, but you brought up
a point that I think I can use (for my defense) : setting up the
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? If the vector was set the way I told it, then cs SHOULD
be coming in pointing right to my routine/DOS mem. I can't debug
through the ISR, but as soon as I uncoment my mov [cs:128 + bx], ah
the program crashes. I can't figure it out.
> One solution I do understand is to assemble your module
>through NASM twice:
>
> The main asm file should be assembled to a bin file in NASM's
>bin format. Then you should have a container ASM file that
>does just an incbin of the bin file and defines symbols for the
>location and length of the result. The container should be
>assembled in COFF format. The symbols in the container will
>be relocated by LD to the load time location of the incbin.
>The symbols in the main ASM file will be bound to offset zero
>by the first assembly and won't be messed up by LD.
Yikes. Kind of lost me here. I'll put this on hold for now.
>> It says you can write
>>
>> mov ax, seg blah
>> mov es, ax
>> mov bx, blah
>>
>> to have es:bx point to blah, but I tried that and NASM says that COFF
>> doesn't support
>
> Right. COFF format doesn't support that (neither does BIN format).
>You could do that in NASM if you were using an ouput format in which
>it were possible. In this case, you shouldn't want to anyway, because
>that code would require the loader to bind the segment. Since you
>move the code after it is loaded, the segment would be wrong.
Yeah, sorry. I was desparetely searching for something to work. That
idea wouldn't have helped me.
>
> Once you get CS correct you can use
>
> mov ax, cs
> mov es, ax
>
> or
>
> push cs
> pop es
>
>> I even tried hacking it by using cs:ip and trying a get an offset
>> using that, but NASM won't let me access IP apparently. How the heck
>> do you make these routines with such limited tools? What am I missing?
>
> None of the limits are in the tools. The difficulties are inherent
>in your decision to load a chunk of 16-bit code as part of a 32-bit
>program and then move it before running it. You just need a
>coherent approach to addressing those difficulties. There are many
>different ways available. The double assembly way was just the
>easiest to explain.
My decision? Is there another way to do bi-modal interrupts without
copying the real-mode isr? I just do that because that's how Watcom
does it. The tools probably aren't limited; I'm just in frustration
mode from smashing my computer with a hammer. If I can't get this to
work soon, I don't think my computer will make it out alive. :)
Anyway, I've become somewhat distracted from this specific problem
because the program is still crashing even with my semi-working
real-mode ISR (just reads the key and acknowledges the interrupt). The
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?
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. It
looks like anytime you do any DOS OS stuff (read files, printf, ....),
DJGPP uses that transfer buffer between DOS memory and the program
memory. Now if those far functions are loading DS with the DOS
selector (which it looks like they are), them my ISR is screwed when
it gets called. I guess I need to load ds with the default DS
selector, but how can I do that.
The nasm docs says that you never have to change selectors, especially
using DJGPP. Are they on drugs?!??!?! If there is a way to allow the
default selectors (cs, ds, es, ss) to have a base of 0 and length of 4
Gig, please let me know. That's the reason I love Watcom for this
stuff. But it isn't true in DJGPP (or CWSDPMI, or whoever sets up the
selectors).
Rock ( = VERY frustrated with DJGPP/NASM)
- Raw text -