Section 2 - Commodore Computers

"6 1-18 COMPUTEI May. May, 1982. Issue 24
to NEWSTT.
What Happens When Applesoft Applesott Runs Into An &
The & symbol is tokenized in the same way thai that
BASICC commands are tokenized, so, even though
& IS is not a proper BASIC "command" (see the
Applesoft AIJ/Jlesofl ReferenceR Manual), the interpreter will
treat it as if it were one. T he & address in the toke n
treat it as if it were one. The & address in the token
lookup table is $03F5 (less {less I). That is, the CHRGET
routine jumped to by the interpreterr will return to
location $3F5 whenn it has fetched the next characterr
following the 8c. At S3F5, there are three free
followi ng the &. At $3F5 , there a re three free
locations, which typically contain an instruction to
jump to some other address, say $0300, where the
actual &- ^--interpreter begins. The &- it-interpreter interpreter will
then typically examinee the contents of the accumu­
lator, which holds the latest character fetched by
C HRGET. and will o pe rate on these in much the
CHRGET, and will operate on these in much the
same mannerr as the Applesoft interpreterr did for
the character it got from CHRGET. H There are
various ways to accomplish this, but the effect will
be to eventually find yet another address (the start
of the command flagged by the &:) &) aand to force a
J M MI* P to that address. The return at the eend off the
subroutine jumped to will be a return back to the
Applesoft IInterpreter and, thence, to NEWSTT,
as described above.
How To Get Rid Of The & in ROM Applesott
How To Get Rid Of The A in ROM Applesoft
QOur UI' goal is to write a command mand token interpreter
which will handle modified Applesoft commands.
We are not worried about things flagged by the 8c
We are not wo rried about things fl agged by the &
which would not otherwise be treated as commands.
We could extend the routine below so that it would
handle these, but, givenn the implementation, (i.e.
as a patch to CHRGET, H which is veryy frequently
called), this would noticeably slow down Applesoft,
called), this would noticeably slow down Applesoft,
so we do not recommend il. it. Further, Funher, we could
extend the interpreter so that it would handle
tokens
which are not commands, allowing modification
of functions.
Again, , we do not recommend
this. Applesoft provides a USR R function with the
explicit intention of allowingg user defined functions.
Our experience ence with functions is that they
are not really y modified at all. Rather, they are
replaced by something quite different, which the
user considers better.
user considers better.
I Inn this case, we feel l thatt the appropriate vehicle
for re place ment is the one d elibe rately built into
for replacement is the one deliberately built into
Applesoft, i.e. USR. An &-based alternative, or an
alternative using this routine, would be inappropriate
as we ll as quite clumsy. Given these limited
riate as well as quite clumsy. Given these limited
objectives, along with a desire (if onlyy to ease our
memory burden) to mimic the Applesoft token
interpretation approach, the modification to ROM
Applesoft in order to allow compatibility witli
flag modified commands is surprisingly straight
memory burden) to mimic the Applesoft token
interpretation approach, the modification to ROM
Applesoft in order to all ow com patability with
RAM Applesoft without requiring ampersands to
flag modified commands is surprisingly straightforward.
Nearl y a ll of ROM Applesoft resides in ROM
Nearly all of ROM Applesoft resides in ROM
and so cannot cannOt be changed. One important rOll routine,
CHRGET, does not reside in ROM. GHRGET is
C H RGET, does not reside in ROM. C HRGET is
loaded into memory whenever A pplesoft is initial­
loaded into memory whenever Applesoft is initial
Ized ized (e.g. by the FP command if youu have a disk).
T his is exactl y the routine ca ll ed by the Applesoft
This is exactly the routine called by the Applesoft
interpreter whenever it wants a new command. We
modify CHRGET so that it jumps to a routine we
call NEWGET, located at $300, which will replace
CHRGET. Along with doing everything CHRGET
used to do, , this routine checks whether the characte
r it fetches is a token in a li st of modified command
ter it fetches is a token in a list of modified command
tokens. If so, it executes that command before
returning to the Applesoft interpeter.
All properly wrillen written Applesoft commands and ·
programs will
leave the TeXT PoinTeR (TXTPTR)
pointing to an eend of ol line following ow g the command,
once the command has been executed. User wriuen
written
commands must conform to this as well. If they d o,
commands must conform to this as well. If they do,
then, when NEWGET finally y returns control to
BASIC, it will pass th e Applesoft interpreter an
BASIC, it will pass the Applesoft interpreter an
"end of line." This forces, as we have seen above, a
branch to NEWSTT, which isjust what we want in
order to avoid confusion in Applesoft over what
order to avoid confusion in Applesoft ove r what
should be executed next.
Further Notes
Here are a few further notes on tl,e the ROM Applesoft
LOke tokenn interpreter In subroutine listed at the end off
thiss article, which may not otherwise be clear From from
the discllssion discussion above.
1. I. The CHRGET routine conceptuallyy divides into
two subsections. The first increments TXTPTR, to
point to the next character. r. The next section is
often called CHRGOT, aand this is the routine
which actuallyy fetches the contents off the locationn
pointed to by TXTPTRR ancl and sets up various internal
flags. By 10adingJMP loading $300 into the first three
bytes o f CHRGET, we effectively destroy the 6-byte
bytes of CHRGET, we effectively destroy the 6-byte
segment of codee which increments nts TXTPTR, and
thus have to repeat this as the first 6 bytes of
NEWGET. In the process, we free the three page 0
NEWGET. In the process, we free the three page 0
locations, $ $B4, $B5, $ $B6, which follow the e J JMPM P
$300. These are used as temporary locations by
NEWGET. The CHRGOT C routine e is completelyy
unaffected by the jump, so we can still use it to
unaffected by the j ump, so we can still use it to
actually fetch the characterr and to set the appropriate
flags (eg. Zero).
2. C H RGET has no effect o n registe rs X a nd Y.
2. CHRGET has no effect on registers X and Y.
We will use both in searching the token table. If we
do not return the original values off X and Y when
we return from frotn NEWGET, WGE1 ~ ,
we will induce errors rs in
the many roUlines routines which call CHRGET and which
assume that this call will not affect tl,ese these registers. rs.
3. Variable FLAG checks whetherr or not a command
is currently being executed. If FLAG is 0, we