Re: .SYSTEM file extensions

[sbdocker@acs.ucalgary.ca (Sean Brendan Dockery)]

In article <24bimt$9bk@sleepy.cc.utexas.edu>
foegelle@sleepy.cc.utexas.edu (Michael Foegelle) writes:

| >BASIC.SYSTEM allocates a 1K intermediate read buffer and donates it to
| >ProDOS. BASIC.SYSTEM then does a ProDOS READ call using the auxilliary
| >address field of the file as the loading point of the file (which
| >happens to be $2000 for all SYS files).
| 
| But it's the BI that's doing the read calls.  Prodos could care less if it
| is a system file or a basic program or a data file or whatever being loaded.
| The BI is doing all the work of specifying what to load and where to load.
| It's the BI's responsibility, not Prodos's.

I'm not disagreeing that BASIC.SYSTEM is doing the specifying of what
file is going to be loaded and where.  But the error is generated by
ProDOS, not BASIC.SYSTEM.

Here comes the big "OOPS!" though...

After re-reading parts of the reference materials I have, I would have
correct myself in that the error generated by ProDOS is caused when
the read call violates its file I/O buffer, not the memory bit map.

It seems that this discussion has gone too long unchecked.  Where were
the Apple.Com supermen who should have been around to save the day? :->

ProDOS returns a ProDOS MLI error code of $56 (BUFFER AREA IN USE) if
you are going to violate any of its file buffers with an MLI call.
BASIC.SYSTEM (when it receives this ProDOS generated error), converts
it to a BI error code of $0C (NO BUFFERS AVAILABLE).

| Minor mis-communication..  The point was that it's not Prodos that protected
| the BI space, but rather the BI.  Prodos doesn't know how much total space
| a system program may need, so how could it possibly protect it?  Same for if
| I wrote a launch utility.  It wouldn't know anything about the memory 
| requirements of the programs it launches.

Miscommunication?  It would seem so.  :-)

I would more properly describe the situation as BASIC.SYSTEM telling
ProDOS to keep an eye on some part of memory while performing MLI
calls (which is accomplished by flagging bits in the ProDOS bitmap).

ProDOS takes care of the memory violations.

The only expectation is that a system program tells ProDOS which
areas of memory to protect.  Without ProDOS's protection scheme, a
system program might often overwrite itself (assuming that it didn't
violate any of ProDOS's file buffers in the process).

| >possible (as BASIC.SYSTEM doesn't care if the GPB is overwritten).
| 
| I'd have to disagree with that.  I've never verified with a system file, 
| but for every other type of file the BI won't overwrite any of its buffers, 
| including the GPB.  I can't imagine why it'd make an exception.  (Well, I 
| CAN, but if the 'No Buffers Available' error when trying to BLOAD something
| over the GPB is caused by the same Prodos bitmap error that gives it when
| loading a system file, then what's the difference?  (Lessee, does that 
| sentence read right...  Yeah, sort of..=)  )

Ahem.  Now that I have had a little time to get prepared, it's time to
bring out the big artillery. :-)

A couple of references from 

	Exploring Apple GS/OS and ProDOS 8
	by Gary B. Little
	Copyright (C) 1988 by Gary B. Little
	Addison-Wesley Publishing Company
	ISBN 0-201-15008-5

First, on pages 58-65, the ProDOS 8 global page is listed.  On page
61, it reads...
----------------------------------------
[...]
                155  * The system bit map.  Each bit in this 24-byte
[...]
                161  * bit will be set to 1.  The configuration of
                162  * the bit map after BASIC.SYSTEM has been
                163  * loaded is shown.
                164
BF58: CF 00 00  165  BITMAP   DFB  $CF,$00,$00 ;Pages 0,1,4-7 inuse
[...]
BF6A: 00 3F FF  171           DFB  $00,$3F,$FF ;Pages $9A-$A7 in use
BF6D: FF FF C3  172           DFB  $FF,$FF,$C3 ;Pages $A8-$B9,$BE-$BF in use
[...]
----------------------------------------
Note that the pages $96-$99 the GPB are *not* marked as in use.  This
means that ProDOS will not generate an error if the GPB is
overwritten.

The GPB is used for CATALOGing disks.  It is probably necessary to
have it unprotected to allow ProDOS to read in a directory file
block at that location (ie: forego the BUFFER AREA IN USE error).

And, from page 237, it reads...
----------------------------------------
[...]
When BASIC.SYSTEM opens a file, it creates a $400-byte buffer for it
by lowering HIMEM by that number of bytes (and moving the general-
purpose buffer down with it) and then reserving the $400-byte area
beginning at the original HIMEM position for use as the buffer.
[...]
----------------------------------------
This allocated buffer (at $9600 if no other files are open) is given
to ProDOS to use as an I/O buffer for the file.  This is noted
somewhere else in the book, but a photographic memory can only hold so
many pictures in its album.  :-)

Summarizing what ProDOS uses this buffer for:

    The first $200 (512) bytes are used to hold the current file data
    block, the second $200 bytes contain the current file index block.
    Only the first half of the buffer is used for a directory file; it
    contains the current directory file block.

It seems that the error resulting from loading large files violates
the file buffer used by ProDOS, not the memory bit map (as I had
mistakenly stated before).

| Yeah, but you're violating Apple's programming guidelines, and thus you 
| shouldn't expect your program to remain compatable with Prodos or other
| programs.  (I actually do something similar to what you say to make old
| DOS 3.3 games run under Prodos.  Of course you have to reboot afterwards
| 'cuz Prodos has been trashed, but..)

Violating Apple's programming guidelines?  It wouldn't be the first
time in history that someone's done that.

Guidelines are proposed to make things run smoothly.  They are not
programming laws.  They are something that you should strive to
maintain.  However, there are times when you have to use unorthodox
methods to get things to work which make it is unavoidable to violate
some of the guidelines, and say (IMHO) "to heck with the system."  :-)

| >Just another moot point, but BASIC.SYSTEM does *not* free its space in
| >the bitmap.  If it *did*, you would *not* get an error when loading a
| >SYS program of $7201 bytes (as was the starting point for this entire
| >discussion).  Also if it did, any error you received would be because
| >your read call would potentially overwrite ProDOS (as that is the
| >first memory block above your loading point that is still marked as
| >used in the ProDOS global page.  In essence, it would be an unloadable
| >system program.

I wrote the above paragraph, but I think that it needs a little
revision (for the benefit of the wider audience).

BASIC.SYSTEM does not free its protected memory when running a
program (Applesoft, binary, text, or system -- it doesn't matter).  It
does free its protected memory when you execute the BYE command.  This
does not violate Apple's Programming Guidelines.

Binary and system programs could recover to BASIC by executing the
jump instruction JMP $03D0 instead of a ProDOS MLI QUIT call.  Even an
RTS instruction would (should) work (assuming that the program didn't
overwrite anything important in memory).

| Yeah.  So ok, I write programs.  I'll write an 'original' program with 
| the .SYSTEM name that is longer than that and send it to you.  Will that
| satisfy you?  =)

Well, sure!  I think that it would depend what the program does.  I
certainly don't want a program containing $7201 or more BRK
instructions called BREAKTHE.SYSTEM, though. :-)

| Yup..  Doesn't mean I agree or anything, but ...  =)

I'm sure you'll come around.  :-)

| Michael Foegelle  | Call Wunderland BBS! |   foegelle@ccwf.cc.utexas.edu
-- 
 internet: dockery@griffin.cuc.ab.ca
      -or- sbdocker@acs.ucalgary.ca
      -or- dockery@pro-calgary.cts.com
 pro-line: dockery@pro-calgary