COM files, ORG 0100h? 
Author Message
 COM files, ORG 0100h?

I'm just curious as to why TASM requires all

a fact WASM doesn't have this requirement.
On another note I'm writing stand-alone
code for an 8088 that runs out of a EPROM,
which requires COM files. I'd like to be able,
eventually, to load my files directly (via an
RS232 link to my proto-board) to an NV
SRAM. Since these would also be stand-
alone files they would also have to be COM
files. Question is, would I be able to make
FAR CALLS from my SRAM-based programs
to procedures in the EPROM?
thanks
Bill Lane


Wed, 26 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?
If I remember correctly, ORG 100 is just a command to designate where the code
begins to execute.......and I don't remember it being
required, for example you could use ORG 200 also.   I could be wrong though, it
has been a while since I messed with ASM

Web Page - mostly History and Latin, no VB yet!.......
http://www.angelfire.com/az/desertavatar/



Wed, 26 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?

Quote:
>If I remember correctly, ORG 100 is just a command to designate where the
>code
>begins to execute.......and I don't remember it being
>required, for example you could use ORG 200 also.   I could be wrong though,

Yes. You are wrong. =)
DOS loads COM files at CS:100h. Because of this, TASM and most assemblers want
to know the correct offsets of all your variables, etc. If you don't tell it,
it definately cannot assemble the right offsets and you'll be screwed
(overwriting other stuff that you shouldn't be). So, you use ORG 100h to tell
the assembler that you want to move the assembler pointer to go to offset 100h
in the code. Since DOS loads the COM file at CS:100h, you must have ORG 100h
before "Start:" (or whatever you use) or else the entry point will not be
correct and the linker will get mad when you try to link it.

  - vulture a.k.a. Sean Stanek



Wed, 26 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?
        On another note, I'm loading my COM files
directly into an EPROM at 0000h. Now since the
EPROM knows nothing about ORG 0100h and only
responds to the address bits A0 - A11 the program
will HAVE to load at F000h despite the fact
that it's ORG'd at 0100h. So since this ORG is
the first statement (and I jump to it from 0FF0
or the last 15 bytes in the EPROM which map to
FFFF0h) will the program counter be changed from
F000h to F100h by the ORG statement?
Bill Lane
A
: to know the correct offsets of all your variables, etc. If you don't tell it,
: it definately cannot assemble the right offsets and you'll be screwed
: (overwriting other stuff that you shouldn't be). So, you use ORG 100h to tell
: the assembler that you want to move the assembler pointer to go to offset 100h
: in the code. Since DOS loads the COM file at CS:100h, you must have ORG 100h
: before "Start:" (or whatever you use) or else the entry point will not be
: correct and the linker will get mad when you try to link it.

:   - vulture a.k.a. Sean Stanek



Thu, 27 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?

Quote:

>         On another note, I'm loading my COM files
> directly into an EPROM at 0000h. Now since the
> EPROM knows nothing about ORG 0100h

  Since you are making an EPROM, don't use ORG 100h
and don't use ".COM" in the image file name.  (Call
it something.bin or almost any other extension).

  "TLINK /t" only requires the ORG 100h if the
output filename is something.COM;  Otherwise,
TLINK expects ORG 0h (and pads for other ORG
values).

  BTW, I wrote my own linker, JLOC, primarily to
help make EPROMs.  For a one module program with
only two fixed offsets (0 and FFF0), you will be
able to get TLINK to do everything you need.

  If you want to have a modular design (build the
image from multiple .OBJ files) or mix C and ASM
in an EPROM or have more than those two fixed
offsets, you need a more flexible linker, such as
JLOC.

  You can download a copy of JLOC with documentation
from my web page.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/



Thu, 27 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?

Quote:

> I'm just curious as to why TASM requires all


TASM doesn't require it; tlink does.  But the rational is that the
thing is going to be loaded at address 100h and the tools need to know
this so they can fix up the offsets properly.  They could have done it
automatically, but opted for the manual approach to make the code more
readable (I suppose)

Question is, would I be able to make

Quote:
> FAR CALLS from my SRAM-based programs
> to procedures in the EPROM?

yes you can do it, but I don't know the syntax off-hand.  You are best
off making a jump table early in the eprom so that you don't have to
deal with recompiling everything if you change the eprom... this might
make syntax issues easier as well.

David

--
---------------------------------------------------------------

http://www.ladsoft.com/index.htm                           (computer
page)
http://www.geocities.com/Area51/Station/5196/index.html    (home page)

http://www.geocities.com/Area51/Station/5196/ttc.html      (tao te
ching)



Thu, 27 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?
[This followup was posted to comp.lang.asm.x86 and a copy was  sent to
the cited author.]



:       On another note, I'm loading my COM files
:directly into an EPROM at 0000h. Now since the
:EPROM knows nothing about ORG 0100h and only
:responds to the address bits A0 - A11 the program
:will HAVE to load at F000h despite the fact
:that it's ORG'd at 0100h. So since this ORG is
:the first statement (and I jump to it from 0FF0
:or the last 15 bytes in the EPROM which map to
:FFFF0h) will the program counter be changed from
:F000h to F100h by the ORG statement?

No!

The advice which you received from Sean Stanek was based on the
assumption that the com file would be loaded and executed by the DOS
command processor. It is incorrect for all other common cases. For your
usage, you need to understand the general case.

The ORG directive, like the ASSUME directive, generates no code. It
leaves its mark at execution time solely as the values which are
generated into instructions which reference memory as an absolute offset
into a segment, and which obtain that offset from labels within your
source code.

Therefore, an ORG at the beginning of a program should always match the
actual load address, which in your case is zero. However, even if the
ORG is incorrect, it is only the references to labeled data areas within
your ROM which will be incorrect, because near jumps are based on a
relative offset from the current instruction pointer, rather than from
the start of the segment.

In addition, you need to keep in mind that the assumption about the
register contents on entry to a com file are based on the behavior of
the DOS command processor. In your case, the only registers you can rely
on are the CS:EIP pair.

Best,
        -- Chuck Crayne
-----------------------------------------------------------

-----------------------------------------------------------

comp.lang.asm.x86 moderation panel member



Thu, 27 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?

Quote:
>:   On another note, I'm loading my COM files
>:directly into an EPROM at 0000h. Now since the
>:EPROM knows nothing about ORG 0100h and only
>:responds to the address bits A0 - A11 the program
>:will HAVE to load at F000h despite the fact
>:that it's ORG'd at 0100h. So since this ORG is
>:the first statement (and I jump to it from 0FF0
>:or the last 15 bytes in the EPROM which map to
>:FFFF0h) will the program counter be changed from
>:F000h to F100h by the ORG statement?

>No!

>The advice which you received from Sean Stanek was based on the
>assumption that the com file would be loaded and executed by the DOS

That's what he wanted - a COM file. =)

Quote:
>command processor. It is incorrect for all other common cases. For your
>usage, you need to understand the general case.

If you want to start somewhere else, use an EXE file. You can ORG 7C00h, for
example, for a bootstrap. If you want some odd location for an EPROM then you
could do similar. Since TLINK has an EXE header and pads anything below the
entry location if you do ORG, I wrote a utility which is in my bootstrap
tutorial to get rid of header info and padding up to CS:IP. You can download my
tutorial at:
 ftp://ftp.ice-digga.com/pub/programming/vul-2.zip

The utility is called CUT.COM (if I remember correctly).

  - vulture a.k.a. Sean Stanek



Thu, 27 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?

Quote:

> The ORG directive, like the ASSUME directive, generates no code. It
> leaves its mark at execution time solely as the values which are
> generated into instructions which reference memory as an absolute offset
> into a segment, and which obtain that offset from labels within your
> source code.

  I can't be certain I understand what you are saying, but if I do, I
am fairly sure you are not correct.  What you are saying fits the way
NASM handles ORG, but NASM doesn't even have ASSUME, and this thread
is about TASM.

  In TASM the ORG directive changes the offset within the current
segment for which the assembler generates code.  If, as a result
of that, there is a gap in the range of output offsets, that gap
will be reflected in the object code, very much like the gap you
would get from "db 100h dup (?)".

  "TLINK /t" decides based on the output filename whether it is
generating .COM format or .BIN format.  In .COM format TLINK
requires an intial gap of 0x100 bytes and excludes that gap
from the output image.  In .BIN format TLINK does not require
any gap and if one is present TLINK will zero fill enough of
the output image to cover it.

Quote:
> Therefore, an ORG at the beginning of a program should always match the
> actual load address, which in your case is zero. However, even if the
> ORG is incorrect, it is only the references to labeled data areas within
> your ROM which will be incorrect, because near jumps are based on a
> relative offset from the current instruction pointer, rather than from
> the start of the segment.

  All of that is exactly what I have said several times to explain
how NASM works in BIN format.  It doesn't fit very well to the way
TASM/TLINK work.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/


Thu, 27 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?


:  All of that is exactly what I have said several times to explain how
:NASM works in BIN format.  It doesn't fit very well to the way
:TASM/TLINK work.

Having now read both your reply and that of Sean Stanek, I believe I
understand how it came to pass that all three of us can be correct,
depending upon how we interpret Bill's question. Both of you seem to
have taken at face value Bill's statement that he wanted a COM file, by
which you understood to mean a file whose format was such that it would
be correctly loaded and executed by the DOS command processor.

However, the rest of his message makes clear that he specifically does
NOT want such a file. What he actually wants is a file which is the
exact image of what he will burn into his EPROM. Since this code will
(as a result of his calling convention) reside at offset zero from the
code segment register, then the assembly source must be ORGed to zero as
well, either explicitly, or by default. Please note that this is
logically the same problem that many people encounter when they try
write boot loader code without realizing that they must ORG to 7c00 to
match the BIOS routine's calling convention.

I now realize that, in your terminology, Bill should have said that he
wanted a BIN file. However, because the only version of TLINK which I
currently have installed does not behave the in the way which you
describe, I was not aware that the DOS based version was so overly
"helpful", and therefore that the term "COM file" had acquired such a
restricted meaning in that environment. Therefore, I assumed that by a
COM file, he meant an executable fiIe which was not in EXE format (i.e.
no header or other information which much be manipulated by a loader). I
will try to be more sensitive to this in the future when referring to a
COM file.

In return, may I ask that you reread my post with the understanding that
neither the question nor the answer were actually about the creation of
an output file, or about the syntax of any particular assembler or
linker, but rather about the function of an ORG statement in any
assembler, and its necessary relationship to the execution time memory
map.

Best,
        -- Chuck Crayne
-----------------------------------------------------------

-----------------------------------------------------------

comp.lang.asm.x86 moderation panel member



Thu, 27 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?
I have been following the discussion and don't understand the confusion.
I programmed quite a number of eprom's with code assembled with MASM and
just make a BIN file I write to the eprom.
This is an example:

                TITLE   UTILROM.ASM

;Code for demo extension ROM

;MASM 6.0 used ML /AT /Fe UTILROM.BIN UTILROM.ASM

;------------------------------------------------------------------------------
CODE            SEGMENT 'CODE'
                ASSUME  DS:CODE,SS:CODE
                ORG     0000H
                .RADIX  10H

UTIL_ROM        PROC    FAR
                DB      55,0AA                  ;Extension Rom ID
                DB      20                      ;Size of Rom 16K = 32 * 512

ROM_ENTRY:      JMP     INIT                    ;Jump to init routine

COPYRIGHT_MESS  DB      " UTILROM ERIC sept 23 1995 "

ADVISE_MESS     DB      "Utility ROM has been loaded",07
ADVISE_LEN      EQU     $ - OFFSET ADVISE_MESS

;Save registers        
INIT:           PUSH    AX
                PUSH    BX
                PUSH    CX
                PUSH    DX
                PUSH    SI
                PUSH    DI
                PUSH    BP
                PUSH    ES
                PUSH    DS
                CLI
                MOV     BP,SP
                STI

                CALL    DO_MESS

;Restore registers
RESTORE:        CLI
                MOV     SP,BP
                STI
                CMP     AX,AX
                POP     DS
                POP     ES
                POP     BP
                POP     DI
                POP     SI
                POP     DX
                POP     CX
                POP     BX
                POP     AX
                RETF
UTIL_ROM        ENDP

DO_MESS         PROC    NEAR
                MOV     AH,03                   ;Get cursor
                XOR     BH,BH                   ;Page 0
                INT     10

                MOV     AH,02                   ;Set cursor
                INC     DH                      ;Next row
                XOR     DL,DL                   ;Column 0
                INT     10

                MOV     AX,0920                 ;Write char/attr
                MOV     BX,000A                 ;Page 0, bright green
                MOV     CX,ADVISE_LEN           ;Length of message
                INT     10

                CLD            
                MOV     SI,OFFSET ADVISE_MESS

TYPE_AGAIN:     MOV     AH,0E                   ;Write teletype
                DB      2E                      ;Segment override CS
                LODSB                           ;Get a byte
                PUSH    SI                      ;Save pointer to next char
                INT     10                      ;Print
                POP     SI                      ;Restore
                LOOP    TYPE_AGAIN
                RET
DO_MESS         ENDP

                ALIGN   10H
                DB      "CHECKSUMCORR"

;Correction for checksum if rest 16K filled with 00's
CHECKSUM_CORR   DW      0000,34B3

;------------------------------------------------------------------------------

CODE            ENDS
                END     UTIL_ROM

--

Eric P. van Westendorp  Tel: +31(0252)210579
Reigerslaan 22  2215NN Voorhout  Netherlands



Fri, 28 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?


:  I have reread it and I still think you are describing how ORG works
:in NASM (which you don't use) rather than how it works in TASM (which
:you do use).

I don't have time to check it right now, but I am going to go out on a
limb and predict that TASM, like all reasonable assemblers, works as
follows:

TASM contains an internal counter, which I shall call the "location
counter", and which is initialized to zero. As TASM processes the source
file, it may encounter various program constructs. However, I will
describe the process only for labels, instructions, data
declarations,and ORG directives. If TASM encounters a label, it enters
the label in the symbol table and assigns it a value equal to the
current value of the location counter. If it encounters an instruction,
it assembles the instruction into a segment memory record and increments
the location counter by the length of the instruction. If it encounters
a data declaration, it moves the initial value of the data into the
segment memory record, and increments the location counter accordingly.
If it encounters an ORG statement, it changes the contents of the
location counter to the value specified in the ORG directive, and writes
out the current segment memory record. [The current segment memory
record is also written when it becomes full, or when the end of the
source file is reached.]

From this process description, we can clearly see that, although no code
is generated as a result of the ORG directive, the generated code which
follows the ORG directive is affected in two ways:

1. The assigned position of the instruction relative to the start of the
segment may be greater or less than it would have been if the ORG
statement had not been encountered.

2. If a machine instruction refers to a local label, the offset which is
encoded into the machine instruction for that label may be greater or
less than it would have been if the ORG statement had not been
encountered.

[As an interesting sidelight, since near jump instructions are relative
to the current instruction pointer, instead of to the beginning of the
segment, they are only affected if an ORG appears between the jump
instruction and the target label. Thus, an incorrect initial ORG will
not have any adverse affect on jumps within the segment. However, Bill
Lane has now informed us that he has an ORG between the end of his main
code and the hardware entry point at the end of the segment. This, of
course, explains his missing 100h bytes.]

Now we come to the obnoxiously user friendly TLINK. The function of a
linker is to turn one or more language translator output streams into a
executable file.  In the specific case of a tiny model file [i.e. one
which is a single segment containing nothing but a single memory image],
all the linker has to do is to copy the segment memory records to their
proper place in the output file. Although there is nothing in the
assembler output which directly relates to the presence of an ORG
directive, the linker can deduce the presence of an initial ORG from the
lowest starting address in the various segment memory records, and TLINK
as taken it upon itself to enforce the concept that a COM file is
intended to be loaded by the DOS command processor, and therefore must
be ORGed to 100h.

However, if the COM file is actually intended to become a boot loader,
device driver, ROM image, program overlay, or any other case where it
will not be handled by the DOS command processor, then it must be ORGed
to match it's intended use, because at execution time -- regardless of
how it is linked and loaded -- the actual memory address must match the
ORG assumption.

To accomplish this with TLINK, link it as BIN, and rename it to COM.

Best,
        -- Chuck Crayne
-----------------------------------------------------------

-----------------------------------------------------------

comp.lang.asm.x86 moderation panel member



Fri, 28 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?
I don't see your logic that these files will be .COM files. TASM makes that
fixed since you have a _psp (program segment prefix, I believe) of 256 bytes
before a com file.


Sat, 29 Sep 2001 03:00:00 GMT  
 COM files, ORG 0100h?
        This has been perhaps a more interesting discussion
of the ORG command than I've gotten out of: three assembly
-based classes (one involving the 8051 and two involving the
8088) and two textbooks. It continually amazes me how little
some of my profs know about the material they're teaching.
        This also explains a lot of the mysterious code I've
seen floating around for my current class. For example,
practically no one can utilize CALLs or RETs with these
stand-alone proto-boards (which have no OS, they simply
execute code according to the CS:IP. I've seen code employing
JMPs w/BP used to save the offset of the simulated CALL
and then JMP BP used as the return.
        I also find it amusing that the term location counter
is misunderstood since it's clearly defined in my TASM 3.0
User's Manual.
        Anyway, thanks for all the help, of the profs who
teach this class, only one of them knew what the hell I
was talking about!
Bill Lane

A
A



Sat, 29 Sep 2001 03:00:00 GMT  
 
 [ 23 post ]  Go to page: [1] [2]

 Relevant Pages 

1. TASM ORG Problem: COM file

2. xml.smalltalk.org, mod.smalltalk.org and camp.smalltalk.org DNS problems resolved

3. you can register .com .net .org domain completely free

4. xml.smalltalk.org and mod.smalltalk.org

5. new host at ruby-lang.org (or rubyist.org)

6. what happened to wxpython.org/wxwindows.org?

7. www.lisp.org and www.alu.org now point to ALU web site

8. missing file for http://raa.ruby-lang.org/list.rhtml?name=shell

9. newbie question: Why is an .exe file much larger than a .com file:

10. COM-Files and resource files

11. How to convert the .exe file to .com file

12. Help in converting exe file to com file

 

 
Powered by phpBB® Forum Software