Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!rutgers!ucla-cs!zen!ucbvax!DMZRZU71.BITNET!mat6013
From: mat6013@DMZRZU71.BITNET
Newsgroups: comp.sys.apple
Subject: Re: //GS Roms, etc
Message-ID: <8708280617.aa13776@SMOKE.BRL.ARPA>
Date: Fri, 28-Aug-87 13:17:15 EDT
Article-I.D.: SMOKE.8708280617.aa13776
Posted: Fri Aug 28 13:17:15 1987
Date-Received: Sun, 30-Aug-87 01:38:12 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 35

To see why an exchange like
 $FD8E: LDA #$8D
        BNE ...      ->     BRA ...
makes high sense look at the following example:

Go into Applesoft mode (prompt ']') and try a "LIST n", 43776a <= n <= 44031b,
a and b are arbitrary strings of at least one digit.  What you expect is a
?SYNTAX ERROR because the numbers are far beyond 63999, the allowed maximum;
but A/S will BReaK into the monitor !  This is because a conditional branch is
misused as an unconditional one.  The code responsible for this is:

              ...
$D981:        JMP $DEC9   ;signal S/N err
              ...
$D9F4:        CMP #$AB    ;GOTO token
              BNE $D981   ;should be a BRA (*only*) when coming from $DA1E
                          ;but the line numbers in the range shown above
                          ;break this assumption !
              ...
$DA0C: LINGET ...         ;This is the start of a routine which convertes
                          ;line numbers from the BASIC text (string
                          ;representation with number base 10) to two byte
                          ;binary integers. Allowed range is 0-63999.
              ...
$DA1E:        BCS $D9F4   ;error exit if out of range; high byte of number
                          ;processed so far in accu

Terrible things occur at $D9F4 when the branch "always" is not taken
(especially a PLA with no counterpart and a RTS).
So, whenever a branch is an unconditional one a BRA should be used if
applicable; this makes the code much clearer and saver. (Software Engineering
isn't incompatible with assembly language ...)

                                        Matthias Kapffer
                                        <MAT6013@DMZRZU71.BITNET>