Re: Problem with NASM
- From: "Rod Pemberton" <do_not_have@xxxxxxxxxxx>
- Date: Sat, 11 Nov 2006 09:28:24 -0500
"Frank Kotler" <fbkotler@xxxxxxxxxxx> wrote in message
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
I'm glad you raised the issue of setting up a sane stack first thing.
(Hmm, you didn't mention the 'cli'... interrupt anyone?)
Well, I'm not detail oriented, so maybe my approach is overkill and not
necessary 97% of the time, but I've learned that for me, it's easier to
attempt to prevent or design out simple mistakes before they occur, than to
spend large amounts of time trying to track them down after I make them...
Obviously, size is an issue in a bootloader, so chopping that code down to
the bare minimum might be necessary whether he wants to be "safe" or not.
But, if he starts out "safe" and reduces the code later on, any problem
should pop up immediately, allowing him to quickly backtrack.
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!
Guess I'll have to reorganize the first example...
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...
It's not good even for advanced programmers... If you'd been on
alt.os.development, you'd have seen some of the problems that came up in
David Lunt's bootloader, such as trying to enable the A20 line in 'unreal'
mode and use of undocumented register values. Cringe!
Odd, why do bootloader posts come up more frequently here than there?
- Re: Problem with NASM
- From: Frank Kotler
- Re: Problem with NASM
- Prev by Date: Re: RosAsm - exports issue with some DLLs
- Next by Date: Re: RosAsm - exports issue with some DLLs
- Previous by thread: Re: Problem with NASM
- Next by thread: Re: Problem with NASM