Subject: Self starting PAL loader?

From: [email-masked] (Douglas W. Jones)
Date: Wed, 9 Jun 1993 17:32:27 GMT

Does anyone ever do this routinely with code intended to be loaded by
the RIM loader?

----- begin example code -----

*20
TOPAD, TOP
       ...
       ...           / other page zero stuff
       ...
       PAGE

TOP,   CLA           / the following code fixes the damage to RIM
       TAD   (5356)
       DCA I (7775)
       ...
       ...	     / your program here
       ...
       JMP I (7756)  / exit to RIM when done

*7775                / patch the RIM loader to start this program	       
       JMP I TOPAD
$

----- end example code -----

This kind of trick works fine with the standard RIM (no matter what
asynch or paper-tape-like device is used), and it saves playing with
the toggle switches so long as your program is bug-free.

					Doug Jones
					[email-masked]

---

From: [email-masked] (Charles Lasner)
Date: Thu, 10 Jun 1993 00:09:11 GMT

>Does anyone ever do this routinely with code intended to be loaded by
[code deleted]
>the toggle switches so long as your program is bug-free.

Yes, this kind of thing is used by such as 8K BASIC and LAB-8/E BASIC.  But
they do a more "dangerous" patch:

They patch the loader to come back to them after the load is over, then
look at the checksum.  If it's OK, they start up, else restart the loader
displaying the checksum error at the HLT.  The problem is of course, what
if the load itself is so far off that this code never regains control?

The self-starting binary loader was invented to handle this situation.  You
end the file with an origin setting which becomes the starting address.  
This is the only loader that obeys that convention, and it's so sloppily
written that it can't easily be modified, already takes up too much space
(meaning requires instructions and/or data in places where some programs
would load over, etc.), and has a genuine bug:

If you use extended memory in your binary file, the last word before the
field-change will erroneously be loaded into the new field following, not
the intended old field!  The workaround is to always end one field of
code with a dummy origin setting which will setup a "sacrificial" loading
into the wrong field, but won't actually load any incorrect data, etc.

Not every program is meant to be used with the self-starting binary loader,
or even the trick Doug mentions, or even the 8K BASIC hack.  The program
must have intimate knowledge of the intended loader before attempting this
trick.  If the RIM loader is definitely what's being used, Doug's trick is
totally valid as he claims.  But if BIN is used instead, then his trick merely
destroys the in-memory RIM loader, or worse, it destroys the corresponding
location within the P?S/8 loader possibly!

cjl