!pr2
A Question About BRUN

Mike Lawrie, a reader in South Africa, reports that he tried our prime benchmark (Sep 85 AAL) in a Titan Accelerator card equipped with a 65802.  It ran 1000 times in 41 seconds, which correlates very nicely with my predictions in the article.  The Titan card runs at 3.58 MHz, and I predicted .35 seconds for 10 repetitions at 4 MHz.

Mike also asked an interesting question, which has been asked by a lot of you at one time or another.  Why is it that some assembly language programs can be BLOADed and CALLed, but not BRUN?  Even the following very simple program will not return from a BRUN, while it will from a BLOAD followed by a CALL:

       JSR $FF3A   Ring the bell
       RTS

The problem is inside the DOS BRUN command.  This command does not use a JSR command to jump to the binary code just loaded.  Rather, it uses a JMP command.  No return address is left on the stack.  When the RTS at the end of the program is executed, it pops garbage off the stack and returns wherever that garbage indicates.  What will happen is rather unpredictable.

The Applesoft CALL command does use JSR, and so it works.  So does the monitor G command, and the S-C Macro Assembler MGO command.  In ProDOS, the BRUN processor works correctly, using a JSR.

This leaves the question:  How should a BRUNnable program end under DOS 3.3?  If it is to return to the command prompt (] for Applesoft) then the last line should be JMP $3D0.  If the BRUN command came from a machine language program (unlikely) then the called program should end with a JMP to a known entry point in the calling program.  The most likely case is an Applesoft program that uses a machine language routine.  The best way to handle this is to use BLOAD and CALL.
