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

[dalloff@freenet.columbus.oh.us (Dave Althoff)]

Grrrrrrr!

As I have posted here, I've been trying to write a file-processing program
to handle certain text files.  As strictly an Applesoft program, it works
great, but it is a little slow.  For a dramatic speed improvement, I want
to have a machine-language string builder to read data from the file.  I
wrote a bit of machine code to do it, and it works great under DOS 3.3, but
mysteriously fails under ProDOS.

First of all, many thanks to everyone who has helped me in the past couple
of days, in particular Neil Parker and OF COURSE Apple ][ Wizard David
Empson.

(drag out Apple box to stand on...)
When I learned how to fiddle with the I/O hooks many years ago, I was
warned that whatever my program did, when it finished it should leave the
machine in the same state as the code it was supposed to replace.  In other
words, if I wrote a routine to change the input cursor or to interpret
"function" keys by changing KSW, I should make sure that my routine exits
leaving the X, Y, and S registers unchanged, and with the final input
character in the Accumulator...and that I shouldn't do any processing
(sticking it in the input buffer, printing it to the screen, etc.) if I
expected my routine to work right with anything else.  It's a good rule;
Applesoft follows it, DOS 3.3 follows it, GPLE does it, even peripheral
cards do it.  Every program I own follows the rule, EXCEPT ONE.  The
outlaw?  None other than BASIC.SYSTEM itself--the program I am growing to
hate more every time I have to deal with it.

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.

I don't care how well documented this might be.  I don't buy the argument
that because Apple, in the process of hacking an add-on for the
system, decided to do it this way that it is correct.  This kind
of nonsense violates the very architecture that makes it possible for the
Apple ][ to do some of the amazing things it is capable of.  The ingenious
system of I/O hooks on the Apple ][ is what makes it possible to send and
receive data anywhere in the system...keyboard, printer, screen, disk file,
modem, etc....using only minor changes in code.  Traditionally, programmers
have been encouraged to use the Monitor I/O routines because they were
written to enable interaction between operating system and peripheral I/O
and any other system add-ons.  A routine that just wants data from the
current input source shouldn't care what state the file management portion
of the operating system is in...the OS should provide information via its
I/O hooks in a consistent manner no matter what it is doing; if the I/O
hook is for a single character of input via the accumulator, the result
should be a single character of data in the accumulator.  Not 256 bytes
blasted into the input buffer.  Is that too much to ask?  I guess so, when
system programs are written by committee.

And people wonder why I hate ProDOS so much.

--Dave Althoff, Jr.

    /-\        _       _               __|\                       
   /XXX\      /X\     /X\_      _     /XX\_\    
  /XXXXX\    /XXX\  _/XXXX\_   /X\   /XXXXX <(hard hat area...       )
_/XXXXXXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXXo(.sig under construction)