TH> But, then again your sentence mechanics implies some
 TH> confusion of your own.
I'm not... Well, now:
COM file,    origin xxxx:0100
Bootrecords, origin 0000:7C00
BIOS chip,   origin F000:0000 (I believe, not 100% sure)
EXE files,   origin xxxx:xxxx (depends on assembler, linker
                               and operating system)
THEREFORE; any 16 bit pointer (not included relative jumps
or any other relative pointer) will be messed up, because
0100 means the first byte in the COM file, but in bootrecords,
it means 0000:0100 (OUTSIDE the entire bootrecord!!). In a
bioschip it would mean F000:0100 if my assumed origin is
correct.
Anyone who's tried (and succeeded) using variables in a
bootrecord knows I'm right...
 TH> While the boot ROM code placed the load area at 7C00, the
 TH> boot record code can work anywhere.
If it contains no pointers/variables whatever, yes.
I don't think very many bootsector will be very well
disassembled as COM files. COM files can't be used as
bootsectors, and bootsectors not as COM files.
You MUST handle origins somehow.
You CANNOT use the same code at another location UNLESS
you keep segment:offset pointers so that they have the
same offset (origin)
 TH> hat was the whole idea behind the segmentation
 TH> architecture of the 80xxx family.
Which you obviously need to study ;-)
(since you don't know about origin problems in realmode)
The entire problems with offsets are unimportant in almost
any code assembled with TASM & TLINK /T that only work with
registers and don't use variables withing their own code.
[peter]
--- FMail 1.02
---------------