TASM ORG Problem: COM file 
Author Message
 TASM ORG Problem: COM file

        I've come across an interesting problem w/TASM
and ORG 0100h. I'm building/programming a stand-alone
proto-board based on the ole' 8088. I've got a boot
EPROM (2732A folks!) of 4K and a NV SRAM of 8K. In
any case, I've mapped the memory thru a decoder to
select address 0FF0 in the EPROM on reset.


do a memory dump from my EPROM the bootstrap
jump is located at 0EF0 NOT 0FF0. Is this because
of the ORG 0100h (since EF0 differs from 0FF0 by
0100h)?
Bill Lane



Thu, 27 Sep 2001 03:00:00 GMT  
 TASM ORG Problem: COM file

Quote:
>    I've come across an interesting problem w/TASM
>and ORG 0100h. I'm building/programming a stand-alone
>proto-board based on the ole' 8088. I've got a boot
>EPROM (2732A folks!) of 4K and a NV SRAM of 8K. In
>any case, I've mapped the memory thru a decoder to
>select address 0FF0 in the EPROM on reset.


>do a memory dump from my EPROM the bootstrap
>jump is located at 0EF0 NOT 0FF0. Is this because
>of the ORG 0100h (since EF0 differs from 0FF0 by
>0100h)?
>Bill Lane

Sounds more like when you're combining your files together you're missing 100h
bytes worth. Try stuffing in a blank 100h byte buffer or change the entry point
to the bootstrap.

  - vulture a.k.a. Sean Stanek



Thu, 27 Sep 2001 03:00:00 GMT  
 TASM ORG Problem: COM file
Both of those options are obvious
solutions. Who would EVER think of
trying those solutions?
TASM sets the location counter according to the ORG directive, ORG 0ff0h should
set the location counter accordingly. I don't see how 0100h
bytes could be "lost" in assembly and
linking. TASM has never "lost" bytes for me before, why would it start now?
Bill Lane


Fri, 28 Sep 2001 03:00:00 GMT  
 TASM ORG Problem: COM file

Quote:

> TASM sets the location counter according to the ORG directive, ORG 0ff0h should
> set the location counter accordingly. I don't see how 0100h
> bytes could be "lost" in assembly and
> linking. TASM has never "lost" bytes for me before, why would it start now?

  All this was answered at length in the other thread you started, which
I thought you would have seen before you posted the above.

  In case it wasn't clear enough, let me try again.

  Don't use ORG 100h and don't name your output file something.COM

  When the output file is named something.COM TLINK (at least the
versions you and I are using) requires that there be a 0x100 byte
gap at the beginning of the segment and it then discards that
gap when writing the .COM file.  

  The result is exactly what you want if you are making a DOS .COM
file (byte zero of the file corresponds to offset 0x100 of the
segment).  It is not at all what you want if you are making an
EPROM image.

  If TLINK (not TASM) has never "lost" 0x100 bytes for you
before, I must assume you never before did a "TLINK /t"
with an output name of something.COM.
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/



Fri, 28 Sep 2001 03:00:00 GMT  
 TASM ORG Problem: COM file
yes, when you org at 100h the com file is generated without bytes 0-0ffh
in it.  So if you burn it straight into an eprom at the address the eprom is
based at you are off by 100h bytes.

David



Sat, 29 Sep 2001 03:00:00 GMT  
 TASM ORG Problem: COM file
Yes, this was duly noted several times.
Additionally I verifed this long ago when I performed a memory dump from my
EPROM.
The question I asked was WHY does
TASM require ORG 100h. Why should anyone be required to waste 256 bytes just to
link a com file. This
was my question yet NO ONE attempted to answer this...
-Bill


Sat, 13 Oct 2001 03:00:00 GMT  
 TASM ORG Problem: COM file

Quote:

> TASM require ORG 100h. Why should anyone be required to waste 256 bytes just to
> link a com file. This
> was my question yet NO ONE attempted to answer this...

  You don't actually "waste" 256 bytes at any point in the process.
I thought each aspect of your question had been answered, but here
I will hit all the important points again.

  When DOS loads a program (COM or EXE) it creates a 0x100 byte
structure that contains various important information associated
with starting and running the program (for example the command
line parameters of the program).  This structure is called the
PSP.

  When DOS loads an EXE, the first segment of the EXE begins at
the end of the PSP.  One consequence of this is that when the
program wants to access its own PSP it must access a segment
different from any of its own (link time) segments.

  When DOS loads a COM, the ONLY segment of the COM begins at
the beginning of the PSP.  The image loaded from the COM file
begins at offset 0x100 in that segment.  That means a COM
program can access its own PSP in the same segment as all its
own code and data.

  This means that each byte from the COM file ends up at an
offset 0x100 higher at run time than it has in the COM file.

  One of the jobs of a linker is to adjust code and data for
offsets like that.  When a module contributes a non-first part
of any public segment in a COM or an EXE, all of that piece
must be adjusted for the total size of all earlier pieces.
If linking of COM files had been sensibly designed, the step
of adjusting the first module for those 0x100 bytes would have
been just a special case of the same type adjustment that
linkers do to every other module.

  However, the linkers weren't designed that way.  They don't
do that first adjustment for COM files.  Instead the programmer
must do it in his source code with ORG.  The ORG (in TASM or
MASM) does two things.  It adjusts the subsequent code to allow
for the 0x100 byte offset between the running image and the COM
file.  It also sets a value in the OBJ file that is equivalent
to telling the linker to waste 0x100 bytes at the beginning of
the image.  The assembler doesn't waste 0x100 bytes, it just
tells the linker to.

  The linker doesn't waste the 0x100 bytes either.  It notices
that the output filename is a .COM (at least some tlink versions
do).  Because of this it both requires that the request to waste
0x100 bytes be present in the OBJ (as proof that the assembler
did the required adjustment for a COM file) and it then skips
the step of actually wasting that 0x100 bytes.  (Because you
don't really want 0x100 bytes wasted;  You just want the image
linked anticipating the 0x100 bytes that DOS will prepend at
load time).
--
http://www.erols.com/johnfine/
http://www.geocities.com/SiliconValley/Peaks/8600/



Sat, 13 Oct 2001 03:00:00 GMT  
 TASM ORG Problem: COM file


:The question I asked was WHY does
:TASM require ORG 100h. Why should anyone be required to waste 256 bytes
:just to link a com file. This
:was my question yet NO ONE attempted to answer this...

It seemed to me that several people attempted to answer this question,
and that John Fine has answered it again at some length, but perhaps a
short summary is also in order.

There are no wasted bytes. TASM itself (by which I mean the assembler
only) does not require ORG 100h, or any other ORG value. TLINK, on the
other hand, assumes that if you intend to name the executable file with
a .COM suffix, then you also intend that the file will be loaded and
executed by the DOS command processor, which places a 100h byte control
block at the beginning of the segment. Therefore, the .COM file will be
loaded at offset 100h. Since the file must be assembled for the same
location as it will ultimately be loaded, TLINK attempts to do you a
favor by not letting you link a .COM file unless it is ORGed to 100h,
because it will not run correctly if it is invoked from the DOS command
line. Other linkers do not have this cumpulsion to be "user friendly".

If you want use TLINK to link a .COM file which will be loaded at some
other offset, tell TLINK to name the file with some other suffix such as
..BIN or .SYS. Then, if you wish, you can rename it to .COM.

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

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

comp.lang.asm.x86 moderation panel member



Sat, 13 Oct 2001 03:00:00 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. Tasm:tlink /t com file problem

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

3. COM files, ORG 0100h?

4. tasm&tlink not generating debug info for a com file

5. Create a com-file with tasm 2.01

6. How do I make Tasm produce .com files?

7. tasm 2.01 how do i compile com files?

8. Can't generate COM file with TASM 2.01

9. Can't generate COM file with TASM 2.01

10. TASM 3 / MMX instructions CMPXCHG ORG

11. TASM 3 / MMX instructions CMPXCHG ORG

12. ORG directive (TASM)

 

 
Powered by phpBB® Forum Software