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!
To fix this, a small delay program SLEEP.EXE is provided, which is always invoked after RESET51.EXE. (see UPLOAD.BAT)