keithe@teklabs.UUCP (Keith Ericson) (10/19/83)
I bought the HES 64FORTH cartridge from the local Toys R Us (same place
I got my C64, so why not...?) and thought I'd let you know what I think
of it.
First, it is pretty generic fig-FORTH. SMUDGE and all. Plus
extensions. They have added both a line editor and screen editor (the
screen editor scrolls horizontally to show 64 chararacters on a 40
character output), a sprite editor and sprite-control words, sound-chip
control words, kernal access words, and disk/file access words.
FORTH source is stored on the disk in files of screens. (I
don't have a datasette(tm) so I can't tell you how well those word
work.) System messages which usually originate from screens 4 & 5 come
from the cartridge in abbreviated form ("error number 4") which you
then look up in the manual. Errors from I/O access and/or kernal usage
generate error-message-numbers that I haven't been able to find in the
manual. (They may come from the kernal directly, and be documented in
the 64 Users' Guide, but I haven't checked that out yet.)
Many of the I/O words are vectored; that's nice because since
it is in cartridge ROM it is impossible to patch the routines if you
want to modify them. The vector table also contains space to hold
user-defined vectors. (I'm not very knowledgable about vectoring
techniques so I can't give a thorough discussion of this topic. Sorry.)
Disk access is slow. Make that s..l..o..w. Make that
s..........l.........o............w..........! I mean, go get a cup of
coffee if you FLUSH more than a few screens. I have a conjecture that
it is really worse than it needs to be. We all know that the 1541 disk
communication is slow, but this is ridiculous! From the statement in
the manual that (paraphrased) "only about 95k of data can be stored on
the disk" I AM MAKING THE ASSUMPTION that they are storing only 128
bytes in each 254-byte sector (that's right, Commodore DOS allows only
254 data bytes; the other 2 are links to the next sector). IF THIS IS
TRUE it would mean that FORTH has to read in essentially twice as many
sectors should be necessary. And it would contribute part of an
explanation for the slow access.
To try to offset the disk access problem there are 16 screen
buffers provided. And if you modify only part of a screen and FLUSH it
to disk only the affected sector seems to be stored. That helps.
The execution speed is not going to set any world records.
Part of the problem is that NEXT is 32 bytes long. (Long-winded
discussion follows - thru remainder of paragraph). The 6502 fails to
properly execute an indirect jump if the address straddles a page
boundary. (the first byte is at location xyFF, the second is at xz00,
where z=y+1: the 6502 picks up the contents of xyFF all right, but
instead of grabbing xz00 it picks up xy00.) There are two predominant
fixes: (1) check the address and treat the special case when it occurs,
or (2) always move the address bytes to a memory location which is
known to not straddle a page boundary and do an indirect jump through
that memory location. HES 64FORTH takes the latter approach.
Two debugging aids are provided: TRACE and EMULATE. Entering
TRACE followed by another (high-level) word will execute the word and
print out the component words as they are executed along with a
representation of the parameter stack. Execution can be interrupted by
hitting the space-bar, and subsequently single stepped (by FORTH word)
by entering STEP, or continued by entering CONT. I have found this to
be an extremely useful facility. EMULATE is essentially TRACE that runs
in single-step mode from the outset: one word is executed and then
execution suspended, resumable with either STEP or CONT.
How would I describe the documentation? Well, "barely adequate"
would be charitable. The little booklet is difficult to use as a
reference book for the software - it won't stay open to the page you
want, and I broke the binding early on in my attempts to get it to do
so. The number of typographical errors is excessive, and several occur
in the sample programs, making it difficult to ascertain whether the
FORTH is broken or the program is broken. There are two nice features
of the booklet worthy of note: (1), an annotated reference to Brodie's
"Starting FORTH" book, detailing the differences, on a page-by-page
basis, between HES 64FORTH and Brodie's (poly)FORTH. That's especially
welcome because a beginniner to FORTH would not be able to do much if
the only information s/he had was based on the 64FORTH booklet. The
other nice feature is the section entitled "What's Missing" where they
describe some of the normally expected beatures that were left out.
(Unfortunately, INDEX is one of the things left out. Fortunately they
list a useable definition for INDEX. Unfortunately it is painfully
slow.)
I haven't had opportunity to use/evaluate the Sprite editor nor
have I used any of the Sound Chip control words. But this note is too
long already anyway. I'll save that for a later news note.
By the way - if anyone knows how I can copy the cartridge into
RAM and execute it from there I would be ESPECIALLY grateful if you
would let me in on the secret(s). I'd like to be able to get in and
patch in some funny stuff to the guts of the system. I can save the ROM
contents to disk and then load the disk file to RAM but nothing I've
tried to get the thing to start running has met with success. The
memory map supplied leads me to believe that the RAM that lives under
the cartridge ROM is otherwise unused so I can`t think of any reason
for it not to work - unless HES has some tricks in the start-up
procedure (which if present should be defeatable in RAM?)
keith ericson at teklabs
uucp: ('|' = 'or'):
aat | arizona | cbosg | chico | cwruecmp }
decvax | eagle | groucho | harpo | ihnss }
lbl-csam | lbl-unix | mit-dspg | ogcvax } !teklabs!keithe
orstcs | orstcsp | pur-ee | purdue | reed }
ssc-vax | ttc | ucbcad | ucbopt | ucbvax }
unc | uophysics | watcgl | watmath | zehntel }
ARPAnet: keithe.tek@rand-relay