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

[spqr@ruth.uucp (Will Baguhn)]

dalloff@freenet.columbus.oh.us (Dave Althoff) writes:

| 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.

yes, that's right... in the ProDOS user's manual it says "Most of your 
basic programs should still work, but machine language things will need 
a major overhaul" (not a direct quote, it's a paraphrase).

as i recall, support for ML handling files as input devices & output 
devices is limited at best.  these techniques were popular when they 
were necessary; face it, we can do better now.
| 
| 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.
| 
| 
| 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.

yes, because you were trying to cut basic.system out of it.  do it 
simply.  BLOAD <file>,A$2000,L$100,B$<x>,TTXT will do wonders for you 
once you understand how it works.

| 
| 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.

have you looked at the spec for the Basic.system system page?  the 
prodos global page?  there's a WEALTH of information there for the 
taking.  the rule of thumb I use for ML with files under ProDOS is "use 
MLI whenever possible".  it REALLY does simplify things when you can 
work around an archaic and broken system.

all in all, it's a whole bunch better than cassette.
| 
| 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)
| 
| 


--- email: uwvax!gorgon!ruth!spqr
Mispeling: the plag of our thyme.