Stéphane thibaud wrote:
....
>>>[ORG 0x0500] doesn't work.
>>
>>"Why not?" would be a start. "org" and ds need to be "synchronized", or
>>the addresses Nasm calculates will be wrong. If you don't want "org
>>0x500" on all your code, a new section...
>>
>>section code_to_move vstart=0x500
>>
>>may help... (???).
>>
>>Another possible issue is the way "MemoryMap_start" is declared. If it's
>>a "struc", "MemoryMap_start.mapsize" will evaluate to the offset from
>>the start of the structure, not a complete memory address - *very*
>>different from the same syntax in C!!! If ".mapsize" is just a local
>>label under MemoryMap_start, it would be the complete address -
>>"correct" or not would depend on "org", if any (or "vstart"), and ds.
>>
>>We may need to see more of your code, if you can't find the problem.
>>What, if any "org" (Nasm defaults to zero, if you don't say), what's in
>>ds, where and how MemoryMap_start is declared, when and how the code
>>gets to be loaded at 0x500... A number of things need to "cooperate" for
>>it all to work... Lessee...
>>
>>mov al,byte[MemoryMap_start.mapSize - Code_start + 0x500] ;0x500
>>
>>"Code_start", assuming that it's in the obvious place, should be equal
>>to "org"... zero if none. If you need a specific "org"... say 0x7C00...
>>the (relatively "new") vstart feature may be what you want. May need
>>some "extras"...
>>
>>org 0x7C00
>>section .text
>>xor ax, ax
>>mov ds, ax
>>...
>>
>>section code_to_move follows=.text align=1 vstart=0x500
>>...
>>mov ds, ??? ;?
>>mov al, [MemoryMap_start.mapsize]
>>...
>>
>>section bootsig follows=code_to_move start=0x7DFE
>>db 0x55, 0xAA
>>
>>(or is it AA 55?) "Something like that"...
>>
>>Best,
>>Frank
>
>
> Hmm... are you talking NASM (sorry for not specifying that I am using
> it)?
Yeah... I thought it looked like Nasm.
> Further more... I'm using the flat-binary format, so I don't have
> the 'sections' as of yet.
You've got a default ".text" section that Nasm makes, even if you don't
specify... Adding multiple sections in a bootsector can be tricky if you
don't know what Nasm does with 'em. Nasm moves ".data" after ".text",
and ".bss" last, unless you mess with 'em. So if you've got a ".data"
section, the boot sig wants to go at the end of that, not ".text". This
has tripped up a few people. Having a ".bss" *after* the boot sig can be
useful - if you understand where it is and don't scribble on it.
Simplest is to stick with ".text", declared or not...
> It's just a bootsector that starts executing
> from 0x500 instead of 0x7C00. About ds: it's zero as is cs.
Hmmm... "org 0x500" ought to work, then. (an alternative would be "org
0" or none, and ds=0x50 - org 0 and ds 0 "shouldn't" be working at all!)
>>section bootsig follows=code_to_move start=0x7DFE
>>db 0x55, 0xAA
>
> Is this possible in nasm? I thought the 'times' keyword was needed to
> fill the space in between.
Yeah, that's the "usual" way to do it. The ability to use arbitrarily
named sections, with "follows", "start", "vstart", "valign", in "-f bin"
mode is a fairly new trick to Nasm. It allows us to separate "virtual
address" from "file offset + org". Other assemblers do this different
ways - multiple "org"s and/or a writeable "$". Nasm allows just one
"org", we can pad to a new file offset with "start" (can't "back up",
which some assemblers will do, I think), or we can calculate addresses
"as if" we had a new "org" without affecting file offset with "vstart".
There are some "good tricks" we can do with this - probably more to be
discovered... But if you're assembling to 0x500, loading to 0x500, and
running at 0x500... you shouldn't need any of that crap.
> I'm curious about these possibilities but I don't think they work on
> flat-binaries...
They do... dunno how "flat" they really are at that point...
I'll combine your next post with this one, okay? (if not... too late! :)
> Oh yeah... and the code gets loaded at 0x500 by my implementation of
> the El Torito standard (bootable CD).
Ah, ha! I wondered how you were running a bootsector from 0x500! (which
was why I assumed there might be "code_to_move"). I'm not familiar with
El Torito - thought it was "just like floppy". Perhaps that's one of
several options...
> The segment was specifiable and
> I checked with Bochs if the code was loaded well... it was.
Okay. That's a good start.
> Another
> thing I noticed was that...
>
> mov al,byte[MemoryMap_start.mapSize]
>
> points to 0xA96A while
>
> mov al,byte[MemoryMap_start.mapSize - Code_start + 0x500]
>
> points to 0x096A - the right address, notice the difference of the
> first A... weird ;)
That is *very* weird!!! Almost as if you had a much-too-large "org"
specified! Assuming that "Code_start" is a label at the top of your
file, it should evaluate the same as "org" - zero if you haven't got
one. Clearly, that's not what's happening! I doubt if it's a "Nasm
version" issue, but if you're using anything between 0.98.40 and 2.02,
you might want to upgrade to be sure (some of the early 64-bit releases
were pretty buggy). http://nasm.sf.net
If you can't get it working, post more...
Best,
Frank
|
