After a bit of research, it turns out it was Applesoft.
The interpreter had a feature where, if it encountered an ampersand during execution of the program, it would unconditionally jump to a subroutine at location $3F5
.
Extension software could use BLOAD
or BRUN
to get some code to a specific location and modify the three bytes at that location. This would then cause the code to execute when &
was seen.
When that code eventually returned, Applesoft would continue execution after the ampersand.
So, if all you wanted was one simple thing to happen when an ampersand was encountered, that would be enough.
In order to allow for more complicated things like &line 1, 1, 20, 50
, the code had to access internal memory to both figure out what the command was (so it could read parameters), and to ensure Applesoft skipped those parameters when we returned. The TXTPTR
Applesoft variable was used for this.
You could call specific functions from your code to parse the line after the ampersand, using TXTPTR
, and adjust it as part of that process, such as with:
; Handles something like "& 12345 * 2, 41"
JSR $DD67 ;FRMNUM - eval numeric expression -> FAC
JSR $E752 ;GETADR - place FAC into memory (LINNUM)
JSR $DEBE ;CHKCOM - check for comma
JSR $E6F8 ;GETBYT - eval byte -> X reg
; Do something in here with registers and memory populated above.
RTS
Granted that's fairly simple but you had ways to ensure that the string "line" was the first thing after the ampersand as well (or detect different commands), giving you a variety of options. There was a GETCHR
which returned the next character (or token if it was a keyword).