Re: Programming *ERROR* in BASIC.SYSTEM! (vent!)

[kindall@falcon.ic.net (Jerry Kindall)]

: dalloff@freenet.columbus.oh.us (Dave Althoff) writes:
: | Under normal circumstances, such as when system input is coming from the
: | keyboard, BASIC.SYSTEM does just what it is supposed to do.  A call to
: | RDCHAR ($FD0C) returns with the keypress in the Accumulator and does little
: | else; I think it even follows through the current input peripheral card if
: | any.  But if a ProDOS READ instruction is active, as when reading a text
: | file, the rules go right out the window.  A call to RDCHAR in this
: | situation, which is supposed to return with a single character in the
: | Accumulator, instead races off to the open file and loads up the input
: | buffer at $200, leaving nothing but garbage in the accumulator.  The result
: | of all this has been three days of head-scratching on my part because my
: | RDLIN routine was using the input line buffer where BASIC.SYSTEM was
: | ILLEGALLY parking the data it should have been passing...making it appear
: | that my program was simply failing to catch certain characters as they came
: | in.  Instead, I was falling victim to a coding ERROR built in to
: | BASIC.SYSTEM.  Yes, an ERROR.  a MISTAKE.  A MAJOR SCREW-UP.

This is a feature, actually.  Basic.System is using ProDOS's newline 
feature to fill up the keyboard buffer (in response to a call to GETLN 
by, say, an INPUT routine) in one swell foop, instead of doing repeated 
single-byte reads.  The X-register is then set to the length of the input 
and the accumulator is set to a carriage return, which fools GETLN into 
thinking that the user has magically typed all that stuff and pressed 
Return in one call to RDKEY.

This makes reading text files CONSIDERABLY faster under Basic.System than 
under DOS 3.3 due to the reduced overhead of single-byte reads.  I would 
definitely consider that a feature.  It's a little sneaky, but then 
sometimes you have to be a little sneaky to get every bit of performance 
possible out of Applesoft.

If you want to read a file from assembly language, you should use ProDOS 
MLI calls to do it.  Or if you want to program in a ProDOS Applesoft 
environment that doesn't do quite so many wacky things, try MicroDot 
from Kitchen Sink Software, which I wrote many moons ago.  (It uses a lot 
less RAM and has several features Basic.System lacks, too.)

--
Jerry Kindall (kindall@ic.net) -- Manual Labor

I pay for this account myself and do not represent Quality Computers via 
this address.  For QC questions & info e-mail quality@genie.geis.com.