!lm10
!rm76
CHRGET and CHRGOT in Applesoft

On pages 13 and 14 of the September 1981 Kilobaud Microcomputing (Robert Baker's Pet-Pourri column) there is a good description of the CHRGET/CHRGOT duo.  These two subroutines (really two entry points into one routine) seem to be common to the Microsoft Basics, at least the 6502 versions.

What are they?  When Applesoft initializes itself one of the tasks is to copy a short subroutine into page zero, from $00B1 through $00C8.  There is no difference between the PET and the Apple versions, except that the PET version is copied into $0070-0087.  Here is the code:

<chrget/chrgot routines here>

Almost every time Applesoft wants to look at a character from your program or even from the input buffer, it does so by calling this subroutine.  The CHRGET entry increments the address used to pick up the next character, and then falls into CHRGOT.  In either case, the character is picked up and several tests are performed.  Blanks are passed over, ignored.  Colon (end of statement) and $00 (end of line) set the Z status bit.  Digits clear CARRY, non-digits set CARRY.  The calling program can use these status bits.  For example:
!lm15

JSR CHRGET
BEQ END        BRANCH IF COLON OR END-OF-LINE
BCC DIGIT      BRANCH IF CHAR IS DIGIT (0-9)
!lm10

The article in Kilobaud suggests patching this routine at $00BA to jump to your own code.  Your program can trap certain characters for special functions, in much the same way as the "&" is now handled by Applesoft.  You just have to be sure that you execute the instructions your JMP overlayed before returning to the remainder of CHRGET.  It appears that many of the enhancement packages available for PET Basic use this scheme.

Why use this patching scheme instead of the "&" for special functions?  Because your special functions can be made to appear an integral part of the language, without the telltale ampersand.  Because even special codes inside expressions or other statements can be trapped.  Because you want to encode or otherwise obfuscate your program for security.  Because you just want to be different.  Of course, the disadvantage is that the entire operation of Applesoft is slowed down by the amount of time your extra testing takes, since every character retrieved by the interpreter will go through your routine as well as the standard CHRGET.

Here is a sample patch program, just show how it is done.  Any time the patch discovers a "#" character, it will ring the Apple's bell.  The sample Applesoft lines show what I mean.  If you want to try out the patch, assemble it and then call Applesoft.  Then get to the monitor and patch CHRGET like this:
!lm15

]CALL -151
*BA:4C 00 03
*3D0G
!lm10

Then enter some Applesoft lines with embedded "#" characters, and RUN.

If you think of some really practical ways to use patches like this, let me know about them.
