Re: .SYSTEM file extensions

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

In article <24ek9l$o99@sleepy.cc.utexas.edu>
foegelle@sleepy.cc.utexas.edu (Michael Foegelle) writes:

| happen then if you tried BLOADing to $9500.  If you're right, then the BI's
| going to push HIMEM down, moving the GPB to $9200-$95FF and use $9600 for
| the loading buffer.  Assuming it didn't generate an error, the BI would 
| then move the buffer and HIMEM all back UP in memory so that what you
| just bloaded ends up at $9900 in the GPB!!  Interesting test..  I'll have

It seems easy enough to do from BASIC.  Let's see..
-------------------------
]CATALOG	(scramble the GPB)
]HGR		(reset page $20 to nulls)
]BSAVE MY.FILE,A$2000,L$400
]BLOAD MY.FILE,A$9200,L$400
]CALL -151	(enter the monitor.. dum dum de dum..)
*9600L		(see if break instructions appear)
-------------------------

| That'd be a rather stupid system program that didn't know where its own 
| code resided in memory!  Not that I'd be surprised to see such a beast,
| and as long as the bitmap remains intact there'd be no problem using it 
| as a key on free space to use as buffer space or whatnot.

Unfortunately, the ProDOS bit map is the only form available to all
system programs in the field of "memory management".

It is too bad that ProDOS didn't come with suite of extentions -- it
would be really useful for a system program to be able to request
dynamic memory allocation, deallocation, relocation, et al without
having to handle such things within the system program itself.

| >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).
| 
| But that assumption can't be made for a system program.  If the system 
| program is a good little program and doesn't overwrite things in the bitmap
| then sure, it can return to the BI.  But if the BI doesn't free its space 
| then any such good little program won't be able to run if it needs that 
| space to run.  Thus not freeing the bitmap sounds like a big mistake to
| me.  (Of course I don't give a @#$% about returning to any other program
| in my own stuff, so in programs like Columns the first thing I do is clear
| the bitmap ('cept for Prodos' space of course, which I don't think can be
| cleared, right?)  That way there's no problem with other programs leaving 
| things in an unknown state.

ProDOS's bit map can be changed, marking all $100 bytes of it as
unprotected.  The only space used by ProDOS in the lower 48K is page
$BF (and a couple of locations in  page $3 too, I guess). The bulk of
the code resides in higher memory (in bank switched RAM).

As for the system program being that "friendly" -- it probably implies
that the program is not doing enough with the system to be considered
a full ProDOS application, and, therefore, should not be classed as a
system program.  I only cited the example because I believe that
BASIC.SYSTEM executes binary and system programs with a JSR
instruction.

| >I'm sure you'll come around.  :-)
| 
| Don't hold your breath...  =)

<quickly turning blue :)>

| Michael Foegelle  | Call Wunderland BBS! |   foegelle@ccwf.cc.utexas.edu

Anyways, I think that subject has been entertained enough by now and
should be put to rest.  It has been fun chatting (arguing, screaming,
grumbling, et al).  :)
-- 
 internet: dockery@griffin.cuc.ab.ca
      -or- sbdocker@acs.ucalgary.ca
      -or- dockery@pro-calgary.cts.com
 pro-line: dockery@pro-calgary