II. Bug Fixes
An attempt to redefine a predefined (SFR) symbol with the /DEFINE command
line option was sometimes sufficient to totally confuse ASEM V1.2!
In these cases, version 1.3 now aborts with a proper runtime error message.
ASEM V1.2 didn't notice, if number type operands of control statements
were not enclosed in parentheses. This has been fixed with version 1.3!
If the location counter symbol $ appeared as the first operand of an
instruction starting in column 1, ASEM V1.2 has flagged it with the
error message
25: 0007 80 00 SJMP $
^
@@@@@ illegal control statement @@@@@
This has been fixed with version 1.3!
ASEM V1.3 does no longer accept the following constructions:
- The start of absolute BIT or DATA segments with BSEG or DSEG
at base addresses above 7FH.
- Memory reservation statements in BIT or DATA segments with
DBIT or DS at locations above 7FH.
- Setting the location counter in BIT or DATA segments with
ORG to locations above 7FH.
- Setting the location counter with ORG to locations below
the segment base address. (Applies to all segments!)
If the first operand of the following instructions
ANL direct, #const8
ORL direct, #const8
XRL direct, #const8
MOV direct, #const8
MOV direct, direct
DB const8, const8
DW const16, const16
contained forward references on pass 1, and was flagged
with one of the following error messages
@@@@@ segment type mismatch @@@@@
@@@@@ attempt to divide by zero @@@@@
@@@@@ invalid bit number @@@@@
@@@@@ invalid base address @@@@@
@@@@@ expression out of range @@@@@
on pass 2, ASEM V1.2 calculated the code lengths of
these instructions different on pass 1 and pass 2,
causing a
@@@@@ phase error @@@@@
for all subsequent label definitions in the same CODE segment.
This has been fixed with version 1.3!
If a frequently used special character like # or @ is read in a position
where an expression is expected, ASEM V1.3 does no longer flag it with
the confusing error message “unary operator expected”, but with
”illegal operand”.
If ASEM.EXE V1.2 had aborted with a runtime error on pass 1,
the previous HEX and list files were left unchanged, because the old output files
were first overwritten between pass 1 and pass 2.
In some cases this was very confusing for the users (and for batch files as well).
Provided the command line parameters are correct, the old output files are
now overwritten by version 1.3 prior to pass 1.
The processor definition file 89C1051.MCU, provided with
version 1.2, was containing the definitions for the AT89C2051
rather than for the AT89C1051! Since the two parts are not register-compatible,
89C1051.MCU has been renamed to 89C2051.MCU,
and 89C1051.MCU has been rewritten.
Sometimes BOOT-51 V1.0 lost characters, if the
”GO TO” command was sent in batch
mode with baudrates greater than 9600 Baud. This has been fixed with
version 1.1.
BOOT-51 V1.1 is now accepting Intel-HEX file
uploads with CR, LF, or CR/LF at the end of line.
BOOT51.DOC has been updated accordingly.
Due to a limitation of the Turbo-Pascal 7.01 runtime system, the program
RESET.EXE crashed with ”Runtime error 200”
on 200 MHz (and faster) Pentium systems!
This has been fixed with release 1.3.
Note: The program has been renamed to RESET51.EXE
to avoid name conflicts.
When assembling short programs on fast computers and uploading them
to the MCS-51 target board at low baudrates with
BOOT.BAT, it could happen that the upload of the HEX file
started before BOOT-51 had fully recovered from (an automatic)
reset. Since BOOT-51 needs some time to output its sign-on
message and prompt, it sometimes missed the upload command, because
ASEM.EXE had finished too fast!
![(smile)](smile.gif)
To fix this, a small delay program SLEEP.EXE is provided,
which is always invoked after RESET51.EXE.
(see UPLOAD.BAT)