Mail Archives: djgpp/1999/07/28/21:14:59
Rock wrote:
>
> 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.
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]
> 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.
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.
> 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.
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.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/
- Raw text -