[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: .SYSTEM file extensions
In article <Aug12.223807.41403@acs.ucalgary.ca> sbdocker@acs.ucalgary.ca (Sean Brendan Dockery) writes:
>In article <24bimt$9bk@sleepy.cc.utexas.edu>
>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.
Ok, makes sense. You're right that a buffer can't be protected by the
bit map, so it has to be something else causing the error. (Still, the
BI won't let you load anything that violates its buffer space. If you
move HIMEM down then you can load above the top buffer (which becomes
the buffer for the file being loaded..) Hmmm.. I wonder what would
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
to try it. I just don't think the BI will allow it though! (Something
to do when I get home!)
>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? :->
Agreed! =) But it's a decent discussion that might enlighten (or bore)
a few people... =)
>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).
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.
>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.
Ok, the BYE command should do that. Good.
>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.
>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. :-)
Well, you're no fun! =)
>I'm sure you'll come around. :-)
Don't hold your breath... =)
> internet: dockery@griffin.cuc.ab.ca
> -or- sbdocker@acs.ucalgary.ca
> -or- dockery@pro-calgary.cts.com
> pro-line: dockery@pro-calgary
Michael Foegelle
--
Michael Foegelle | Call Wunderland BBS! | foegelle@ccwf.cc.utexas.edu
University of | (512) 472-0544 8n1 | foegelle@utaphy.ph.utexas.edu
Texas at Austin | 14.4kbaud, v.32/bis | GEnie: M.FOEGELLE2
Physics Department | 500 megs on a //e! | > Ask me about Columns //e! <