Re: Problem with NASM

Rod Pemberton wrote:
"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
news:ZIudnQw07pjbBcnYnZ2dnUVZ_o2dnZ2d@xxxxxxxxxxxxxx

Rod Pemberton wrote:

...
A you write your boot sector, you'll also need to keep checking that
your
compiled boot code actually fits into 512 bytes. NASM will generate
wierd
negative offsets if the code size exceeds 510 bytes. (been there...)

??? Barfs up an error message about the argument to "times" being
negative, for me.

Odd...

I am using the DOS versions of NASM which may be slighty older than the Win
versions.

Could be a version problem. I seem to recall that "times" was one of the things that got broken, when we broke things.

(I would remind everybody that older versions of Nasm have a potentially exploitable buffer overflow... although I doubt anyone's targetting Nasm)

You'll probably also want code to set the cs to 0x0, ip to 0x7c00 or cs
to
0x07c0, ip to 0.

Why? The bios "almost" certainly jumps to 0:7C00. If some weird bios
*does* jump to 7C0:0, how does that bother us?

If there is a mismatch, say code is ORG'd for 0:7c00 and the BIOS jumps to
7C0:0, all offsets in his code will be incorrect relative to CS.

True, relative to cs...

Let's say that at some point he runs out of segment registers,

In a bootsector? Okay...

now he'd like
to use a CS segment override to access data in the DS segment, but CS isn't
set to the DS segment.

True, that won't work.

Let's say he uses an absolute indirect near jmp

In a bootsector? Okay...

to an address. If that jump
is supposed to be to 07c3dh, instead of jumping to 0:7c3dh, his code jumps
to 07c0:7c3dh because the segment CS is incorrect.

True enough.

Let's say he needs a computed jump using retf to transfer to his OS. He
goes to calculate his address using CS,

Uhhh... We presumably just read (or copied) our OS to where it is. I don't know why we'd be using cs to calculate it...

which is an error, because he didn't
set CS to DS or didn't realize he should've used DS instead.

True enough.

Also, DS and SS aren't guaranteed to be set to anything of value

Absolutely! And the fact that *sometimes* ds *does* happen to be set to zero (my machine) only adds to the confusion!

which means
that any reference to memory or the stack, could be incorrect, until they
are set. So, since he should set these, he might as well set CS too.

Mmmm... "might as well", I suppose...

If he
doesn't, the jmp setting CS will just be replaced with a mov reg, value or
xor reg,reg instruction for setting the other segments.

True. Once we've made a far jump, we can do "push cs"/"pop ds"... I see a lot of bootsectors that count on that, *without* the far jump. Enough of them so that it must not go wrong often. Supposedly, some Compaq Presario models *do* jump to 7C0:0...

I agree that if we do any of the things above, we should do a far jump to guarantee we know what cs is - although it's a "pretty safe" bet it's zero. I usually go with an explicit zero (or 7C0h) for ds, and let cs be "whatever" because I haven't had the need to do any of those things. I figure I'll be doing a far jump (or retf) soon enough, and don't really need to know what cs is "now". But it's cheap enough to do, and allows some "tricks"...

I'm glad you raised the issue of setting up a sane stack first thing. That's important!

We know there has to be the signature at the end - my bios doesn't even care about that, but many do. I've "heard of", but never seen, a bios that also insists that a bootsector start with a "jmp near" or "jump short"/"nop" or it'd claim "non-system disk". That one's even rarer than jumping to 7C0:0, I imagine, but... we can assume very little!

In a way, a bootsector isn't a good project for a beginner, although a lot of 'em want to do it - too hard to troubleshoot (Bochs is not real hardware), and too easy to get something that works on "my machine" but isn't "generic". But there's a sense of satisfaction to it, and you can learn a lot...

Best,
Frank
.

Relevant Pages

  • Re: Odd problem with int 0x21, ah = 0x4A
    ... segment _TEXT16 use16 ... But Nasm does not make a "symbol" out of section names in "-f bin" mode, so the assembly errors out when you try to use it. ... - what our load segment is, so we should be able to patch the places these are used. ... we overwrite that funny value we put in ecx - this ecx is used to set esp after the jump to 64-bit code. ...
    (comp.lang.asm.x86)
  • Re: NASM - VC++ Linking Problems
    ... My "experiment" didn't have a "section" or "segment" directive, and still the symbol appeared in the .obj. ... In an output format where it's valid, Nasm should export a "global" symbol - no excuses! ... (I don't mean to knock Watcom - I haven't tried WASM, but the openwatcom package as a whole is quite nice - unless I'm mistaken, the Windows executable of Nasm at SF was built by Watcom - running on Linux!) ... knows about the name mangling scheme used by its "companion" compiler, ...
    (comp.lang.asm.x86)
  • problem in hooking cocreateinstance
    ... what Detours does is quite "easy": ... appends to G a jump to &F. ... Since I didn't want to write a table of IA-32 opcodes by ... wholly inside this segment, or it has to perform an absolute ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: NASM - VC++ Linking Problems
    ... My "experiment" didn't have a "section" or "segment" directive, and still the symbol appeared in the .obj. ... In an output format where it's valid, Nasm should export a "global" symbol - no excuses! ... myfunc = VC_mangled_name ... If you find that Nasm is really neglecting to export your globals... ...
    (comp.lang.asm.x86)
  • Re: Pointer?
    ... Yes, Nasm syntax is different. ... Whether Nasm accepts "seg" or not depends on which output format you've ... segment value in cs, ds, es, ss, fs, and gs. ... mov bp, hello ...
    (alt.lang.asm)