Hex Constants in Applesoft....................David Bartley

Coding in BASIC has several frustrations for the assembly language programmer.  One small but constant irritant for me has been the inability to directly specify hexadecimal values in Applesoft statements or in response to an INPUT command.  I finally decided to do something about it when I read Bob Sander-Cederlof's article on the CHRGET routine in the September Apple Assembly Line.  The result is the short program shown here.

My goal was to be able to enter a hex constant, defined as a "$" followed by one or more hex digits, anywhere Applesoft would allow an integer constant to appear.  I nearly succeeded -- I'll discuss the exceptions a little later.  I now can write statements like:

       100 FOR I = $0 TO $FF
       110 INPUT X,Y
       120 Z(I) = $100*X + Y - $3DEF

The responses to the INPUT statement may also be hex constants.  Values may range from -$FFFF (-65535) to $FFFF (65535); the left-most bit is not considered a sign bit.

My program is set up by BRUN-ning the object file XB.A/S HEX CONSTANTS (see line 1010).  Initialization consists of modifying the Applesoft CHRGET subroutine to branch into new code starting at line 1400.  As you may recall, CHRGET is used by the BASIC interpreter to fetch characters and tokens from the program text of keyboard when a program is executing.  The new CHRGET code watches for a "$" character; when one is found, it scans forward until it hits a character which is not a hex digit, converting to a binary value (in VAL) on the fly.

Variable IDX serves two purposes.  It is normally negative, signifying that characters are to be fetched without special action until a "$" is encountered.  After a hex constant is found and converted to a binary value, IDX becomes a positive index into a power-of-ten table to facilitate converting VAL to a decimal value.  Each subsequent call to CHRGET then returns a successive character of the decimal integer representation of VAL until IDX becomes -1, the entire value has been transformed from hex to decimal, and the normal mode is restored.

There are, of course, several complications.  One is the BASIC "DEF" command, which happens to consist of a string of hex digits.  Applesoft therefore parses a constant like "$3DEF" as the ASCII characters "$" and "3" followed by the DEF token (hex 88).  Lines 1760 to 1840 take care of that.

A more serious complication is the existence of a frequently used alternate entry point to CHRGET callled CHRGOT.  CHRGOT is called to fetch the previous item from the text rather than the next one.  It seems that numeric constants are parsed from several places within the Applesoft interpreter, with some using CHRGOT and others not.  When I fixed things up so CHRGOT would work for inline constants and the INPUT command, it no longer worked for values in DATA statements (or for hex line numbers, for that matter!)

The trick that makes CHRGOT work (most of the time) is to back up TXTPTR and then return a leading zero to start off the converted decimal value.  The zero causes no consternation for the parts of the interpreter that see it and is not missed by those that don't.  If CHRGOT is not called, however, TXTPTR should not be backed up.  You can't win!

I hope others will be able to make use of this routine -- better, that someone will overcome the problem with DATA statement values.  It has been quite valuable to me as it is, as well as quite an education in understanding the inner workings of the Applesoft interpreter.
