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
Extension software could use
BRUNto 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.
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).