From: "John S. Fine" Newsgroups: comp.os.msdos.djgpp Subject: Re: Nasm and real-mode ISRs (bimodal) Date: Fri, 23 Jul 1999 10:12:02 -0400 Lines: 89 Message-ID: <37987832.ADD@erols.com> References: <379739de DOT 5187825 AT news DOT ntplx DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: C5ApOFumI+E1A3b9QmX3rF6QASvjKiq25T2z8wMAw/E= X-Complaints-To: abuse AT rcn DOT com NNTP-Posting-Date: 23 Jul 1999 14:14:06 GMT X-Mailer: Mozilla 3.01 (Win95; U) To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com 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/