Programs compiled with Intel's ASM86 won't run under DOS operating system

On 31 Mar 2004 03:48:40 GMT, Grant Edwards <grante@visi.com> wrote:

> On 2004-03-31, PISZCZ, Bogdan <b.piszcz@t-online.de> wrote:
>
>> But the .hex file is loaded into memory and launched on an embedded
>> system.
>
> Then there's a loader program running on the embedded system
> that's converting the hex file back into binary before running
> it.
>
>> What I don?t understand: how can an ASCII file run on a processor,
>> with or without OS?
>
> It isn't.  It's converted back into binary before being run.
>


Why isn't a binary file transferred straight to the microcontroller, 
without being subjected to an interim (hexadecimal or ASCII) form 
convertion?

There is no point in converting a binary file (filename without extension 
in the pertaining case) into a hexadecimal ASCII file (filename.hex) and 
then back into a binary file, isn't it?


Bogdan

In comp.arch.embedded, "PISZCZ, Bogdan" <b.piszcz@t-online.de> wrote:

>On 31 Mar 2004 03:48:40 GMT, Grant Edwards <grante@visi.com> wrote:
>
>> On 2004-03-31, PISZCZ, Bogdan <b.piszcz@t-online.de> wrote:
>>
>>> But the .hex file is loaded into memory and launched on an embedded
>>> system.
>>
>> Then there's a loader program running on the embedded system
>> that's converting the hex file back into binary before running
>> it.
>>
>>> What I don?t understand: how can an ASCII file run on a processor,
>>> with or without OS?
>>
>> It isn't.  It's converted back into binary before being run.
>>
>
>
>Why isn't a binary file transferred straight to the microcontroller, 
>without being subjected to an interim (hexadecimal or ASCII) form 
>convertion?
>
>There is no point in converting a binary file (filename without extension 
>in the pertaining case) into a hexadecimal ASCII file (filename.hex) and 
>then back into a binary file, isn't it?

   Yes, but these object files have traditionally (a long, long time
ago, in a development system far, far away) been put on various media
such as punched paper tape (IIR it was 7 bits, or if 8, it was used as
7-bit ASCII with the 8th bit unused or used for parity), and errors
were quite possible in the transfer to the final device (processor RAM
or EPROM, emulator or EPROM programmer). The Intel hex, Motorola 's'
and other such formats have checksum bytes at the end of each 'block'
so a problem such as a dropped bit was at least detected.
   But you're right, nowadays everything is on 'reliable' media (such
as floppy disk or tcp/ip networks) that have their own CRC checks, so
binary files will work fine. Only an old fart would know why those
.hex files were ever used.

   I remember the first Z8 OTP I tried to program, when they were
about $15 each. I really felt awful when I saw I had programmed it
with an image of the .hex file. I knew better, but somehow I had
picked the wrong option on the programmer.

>
>
>Bogdan

-----
http://mindspring.com/~benbradley

On Thu, 01 Apr 2004 05:44:37 +0200, "PISZCZ, Bogdan"
<b.piszcz@t-online.de> wrote:

>>> What I don?t understand: how can an ASCII file run on a processor,
>>> with or without OS?
>>
>> It isn't.  It's converted back into binary before being run.
>>
>
>
>Why isn't a binary file transferred straight to the microcontroller, 
>without being subjected to an interim (hexadecimal or ASCII) form 
>convertion?

You need some kind of protocol for transferring the program from the
development system to the target system. How would the target system
know when the data starts and when it ends, how do you specify load
addresses to the loader etc. if you only have a blob of bytes ?

Those old HEX formats were developed when paper tapes were common. If
you are transferring the 0x00 byte in binary, how do you know when
this is actual data and not part of the blank leader or trailer ?

Instead of dedicated tape punches and readers with some kind of
parallel interface, it was quite common to use a Teletype with a paper
tape punch to generate the tape and transfer the tape to an other
Teletype paper tape reader or a dedicated paper tape reader to load
the program each time the target system was started. The Teletype only
had 7 bits+parity, so how would you transfer 8 bit bytes ?

Later on the serial port --> Teletype --> paper tape -->Teletype -->
serial port chain was replaced by direct serial port --> serial port
connection without changing the protocol.

Paul
   

PISZCZ, Bogdan <b.piszcz@t-online.de> wrote:

> Nevertheless, both, the TASM linker and the MASM 6.11 linker produce the 
> warning "no stack segment" or "no stack", respectively. 

IIRC, that warning is expected if you're building a tiny-model program
in raw assembler without specifying you want to build a .com program.
And it's harmless.

> Regarding the warning "program has no starting address" (produced
> only by MASM 6.11 linker): doesn't the OS locate the program in the
> memory (i.e. assign the program its starting address)?

That missing "starting address" is the ORG statement you've been told
about before.  

> Why doesn't the TASM linker complain either?

Because it's designed to allow sloppier coding.  It even says so in
its manual somewhere.  I.e. if you omit some setting, it'll just
assume you meant the usual value of that setting.

> Why didn't it work before - with Intel's linker? What's the
> difference in the function between Intel's linker and other linker?

They're different linkers, written at different times by different
people.  Which means they're *completely* different, probably.  Asking
for individual differences doesn't really make sense in that
situation.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

"PISZCZ, Bogdan"

> One more question:
> Why didn't it work before - with Intel's linker? What's the difference
in
> the function between Intel's linker and other linker?

The version of the Intel linker that you have doesnt know how to do
this:
http://www.iro.umontreal.ca/~feeley/cours/ift2240/doc/assembly/programsegmentprefix.html

The compilers and assemblers produce raw object code that is not yet
ready to load into memory.  Unless otherwise specified within the
module, the object code will expect to be loaded starting at memory
location 0.  Modules may also contain references to other modules, but
the compiler/assembler doesn't yet know where these other modules will
be loaded into memory.  The OS (if present) also needs a mechanism to
enter/exit your main module.  The linker must perform all these
functions and more.

Hans-Bernhard Broeker wrote:

--- clip clip --

>>Why didn't it work before - with Intel's linker? What's the
>>difference in the function between Intel's linker and other linker?
> 

The Microsoft .obj format is a mutilated subset of the
original Intel iAPX86 Relocatable Object File Format.

The DOS linkers do two operations at one time: bind
different object modules together and locate them
to pre-determined memory addresses (almost). The
canonical offset part of the address will be located,
but the segment part is relocatable relative to the
file start. If the ultimate target is a .com file,
there must be no segment relocations left in the .exe
file, so it can be converted to a .com file with the
exe2bin utility.

The Intel relocation scheme separates the linking
and locating steps: there are two utilities: link
and locate. Link binds the relocatable modules
together and produces a bound, still relocatable
output file in the same .obj format. Locate locates
the relocatable sections (or some of them) in the
input file and outputs a located file in the
.obj format. The located file can later be  bound
with other files to create e.g. overlays or
system ROM calls.

The Microsoft and Intel object formats are not
entirely compatible. With some limitations, it is
possible to write a converter for transforming
an Intel file to the Microsoft format for final
linking with a DOS linker.

HTH

Tauno Voipio
tauno voipio @ iki fi

PS. 'No start address' means that you have not specified
the program starting point in the 'end' directive of the
main module.

TV