Hiya all.

using tasm v4.1 and tlink version 7.1.30.1, running under dos 6.22

I am trying to write boot sector code (for an OS I am planning to write). I
need my code to have an entry point of 0000:7c00h (7c00h). (so that all
references/offsets to data are computed relative to this address)

When using the "org" directive to specify an entry point, it does not work.
I am trying to generate
a .com file. I understand that the official .com standard has an entry point
of 100h, but this is not suitable
for my application, nor is .EXE format (must have straight out code, no
header)

any way to override this? or another way to produce a plain binary image?

If I use nasm under FreeBSD, and use org 7c00h
things work perfectly. Unfortunately, most of my development tools (that I
wrote)
have been written for DOS and cannot be ported without a lot of headaches,
so I would prefer to do my work under DOS.

Alex.

PS: I have tried the borland tasm group, but dont feel like waiting a month
for
a reply there. Someone here must have had some experience with borland tasm.

> Hiya all.
>
> using tasm v4.1 and tlink version 7.1.30.1, running under dos 6.22
>
> I am trying to write boot sector code (for an OS I am planning to write).
I
> need my code to have an entry point of 0000:7c00h (7c00h). (so that all
> references/offsets to data are computed relative to this address)
>
> When using the "org" directive to specify an entry point, it does not
work.
> I am trying to generate
> a .com file. I understand that the official .com standard has an entry
point
> of 100h, but this is not suitable
> for my application, nor is .EXE format (must have straight out code, no
> header)
>
> any way to override this? or another way to produce a plain binary image?

It does work, maybe it's just that you don't know how to force it to do what
you want.
try this (if I haven't made a mistake, it must work as is, at least it
compiles and links and disassembly looks fine too):
---8<---
;filename: z.asm
;compile:
;tasm /m2 z.asm
;tlink /t z.obj, z.bin

myseg segment use16
assume cs:myseg,ds:myseg,es:myseg
org 7c00h
start:

db 0eah ; far jump to 0:continue
dw offset continue
dw 0
continue:

xor ax, ax
mov ds, ax
lea si, msg

mov ax, 0b800h
mov es, ax
mov di, 0

cld
mov cx, msgend-msg
rep movsb

jmp short $

msg db "h e l l o   w o r l d   ! "
msgend label

myseg ends

end start

---8<---

If I'm not mistaken, the key point is the filename extension. Don't put
com. Right, just try .bin and then .com :)

> If I use nasm under FreeBSD, and use org 7c00h
> things work perfectly. Unfortunately, most of my development tools (that I
> wrote)
> have been written for DOS and cannot be ported without a lot of headaches,
> so I would prefer to do my work under DOS.
>
> Alex.
>
> PS: I have tried the borland tasm group, but dont feel like waiting a
month
> for
> a reply there. Someone here must have had some experience with borland
tasm.

It does work, but IMO ASM gurus are rare these days :)

Get going!
Alex

alex wrote:

> If I use nasm under FreeBSD, and use org 7c00h
> things work perfectly. Unfortunately, most of my development tools (that I
> wrote)
> have been written for DOS and cannot be ported without a lot of headaches,
> so I would prefer to do my work under DOS.

DOS is dead. Long Live DOS!!! :) I think Alexei's given you the secret 
for making Tasm work. I know, Tasm users like Tasm. But I'd point out 
that Nasm is available for DOS (get the 32-bit "dos extender" version - 
Nasm16 is for 286s - please!). The bootsector code you've developed 
under FreeBSD should work just the same assembled under DOS - of course 
you haven't got dd to write it to disk :)

Or perhaps your development tools are Tasm-specific. Out of curiousity, 
what's your favorite home-made development tool?

Maybe I should point out that in Nasm 0.98.37, "-f elf" (that wonderful 
new -f elf with the "stabs" debug-info that I've been touting?) has some 
serious problems. You might want to avoid it for FreeBSD. The fix will 
be along shortly, we hope. On the other hand, the debug-info for 
Borland's Turbo Debugger is "fixed" in 0.98.37, so that's the one you'd 
want if you have any interest in using Nasm with TD. I say "fixed"... 
it's better than it was (since 0.98.15 or so). We're looking for 
feedback, if anyone is using that combo.

Anyway, latest Nasm at http://nasm.sourceforge.net

Happy Bootin'
Frank

P.S. Re: Your posting problems... Posts take a while to show up here, 
unlike an unmoderated group. Chuck won't reject your posts unless you're 
*totally* off-topic, and you'd get a notice then, if your address is 
valid. But see "If you're having trouble posting" - I cc everything to 
clax86-submit at crayne dot org to be on the safe side. Probably a PITA 
to Chuck, but my posts show up :)

"alex" <alex10@ihug.com.au> wrote in message
news:bjhju1$a29$1@lust.ihug.co.nz...
> Hiya all.

hi...

(snip)

> If I use nasm under FreeBSD, and use org 7c00h
> things work perfectly. Unfortunately, most of my development tools (that I
> wrote)
> have been written for DOS and cannot be ported without a lot of headaches,
> so I would prefer to do my work under DOS.

get a version of nasm for dos...
http://sourceforge.net/projects/nasm

hope that'll help you...
(that reminds me.. i better get me a version for dos while i'm thinking
about it...)

Hi :)

----- Original Message -----
From: "Frank Kotler" <fbkotler@comcast.net>
Newsgroups: comp.lang.asm.x86
Sent: Tuesday, September 09, 2003 11:22 AM
Subject: Re: entry point for code


> DOS is dead. Long Live DOS!!! :) I think Alexei's given you the secret
> for making Tasm work. I know, Tasm users like Tasm.

DOS is dead :] I'd agree :) but it provides me with a good development
environment for playing around with the hardware and debugging code :)

Nasm seems to have some strange quirks which I am not used to
eg:

padding db 100 dup(0)

wont work under nasm, they have the "times" directive which I found rather
odd. Just silly things like that, are keeping me away from nasm. I also
like borlands TD :] its often helped me to track down some bugs that
are hard to spot with the naked eye ;)

>The bootsector code you've developed
> under FreeBSD should work just the same assembled under DOS - of course
> you haven't got dd to write it to disk :)

I've written my own utility to read/dump disk sectors :] it also allows me
to modify/view any of the BPB area in a standard bootblock :)

>
> Or perhaps your development tools are Tasm-specific. Out of curiousity,
> what's your favorite home-made development tool?
>

not really tasm specific, but I have written tools to assist me in GUI
development etc
(font generation tools etc) which make use of DPMI calls and hardware level
I/O under DOS
which isnt really portable to FreeBSD.

I am rather pleased with the responses I have recieved and I thank both you
and alexei
for your advice :)

Regards, Alex

alex wrote:

> DOS is dead :] I'd agree :) but it provides me with a good development
> environment for playing around with the hardware and debugging code :)

Agreed. As an OS, dos isn't so hot. But if you think of it as a second 
stage bootloader, it's very full-featured, if somewhat bloated :)

> Nasm seems to have some strange quirks which I am not used to
> eg:
> 
> padding db 100 dup(0)
> 
> wont work under nasm, they have the "times" directive which I found rather
> odd. Just silly things like that, are keeping me away from nasm.

Too bad. I agree that the "times" directive is an odd one - for some 
reason, people don't like to use it. It isn't *that* ugly:

padding times 100 db 0

Bit of a PITA that the "operand" (which can be an expression, not just 
an immediate) comes in a different order than with "dup" - makes 
"translating" Masm/Tasm to Nasm a nuisance! But for uninitialized data, 
I like Nasm's:

buffer resb 100

better than:

buffer db 100 dup(?)

so it's kind of a tradeoff...

> I also
> like borlands TD :] its often helped me to track down some bugs that
> are hard to spot with the naked eye ;)

Yeah, TD is nice. Nasm's support for it is imperfect - the "-g" switch 
with "-f obj" will get you some symbolic debug-info TD can use, but it 
isn't quite right. No support for a ".sym" file from "-f bin" output, 
but we can now produce a "map" file, which I see as a possible "start" 
towards it...

Best,
Frank