Re: Prodos Woes

[dalloff@gcfn.org (Dave Althoff Jr)]

Michael J. Mahon (mjmahon@aol.com) wrote:
: >: You can punch in and save as follows:
: >
: >: ]CALL -151
: >: *300:A9 00 85 06 85 08 A9 04 85 09 A9 60 85 07 A0 00 B1 06 91 08 C8 D0 F9
: >: *:E6 07 E6 09 A9 08 18 C5 09 B0 EC 60
: >: *3D0G
: >: ]BSAVE MOVER,A$300,L$24
: >
: >: ...then in the BASIC...
: >: nnnnn PRINT CHR$(4);"BLOAD MOVER"
: >: nnnno PRINT CHR$(4);"BLOAD TEXTSCREEN,A$6000":CALL 768
: >: nnnnp WAIT 49152,128:GET K$
: >
: >Once I changed the comparison at 320, it worked.

: And it still clobbers the screen holes.

: If clobbering the holes is acceptable (!), then bracketing the BLOAD
: with a couple of POKEs to the ProDOS memory map will do it.  (Or
: just one POKE if you don't mind leaving low memory unprotected.)

Yes, it clobbers the screen holes.  But I have not yet encountered a
problem that comes from clobbering the screen holes when nothing else is
going on.  Programmers who use screen holes are generally smart enough to
realize that there is a very good chance that those memory locations are
not safe, that they will be clobbered, because they are not documented in
a memory map.  The safe way to use screen holes (and in fact, the way they
seem to be used most frequently) is to only use them while you have
control of the computer.  Once you relinquish control to someone else (via
an RTS, for example...) that memory isn't yours anymore, and you should
expect it to get clobbered.  Even if your name happens to be BASIC.SYSTEM
or P8.  ProDOS won't let you load into the screen holes directly because
it uses the screen holes during disk I/O functions.  But it's smart enough
to not count on those holes when it isn't otherwise doing anything.

--Dave Althoff, ][.
-- 
    /*\        _       _               _   *** Merry Christmas!!! ***
   /###\      /X\     /X\_      _     /X\__      _     _        _____
  /#####\    /XXX\  _/XXXX\_   /X\   /XXXXX\    /X\   /X\      /XXXXX
_/XXX#XXX\__/XXXXX\/XXXXXXXX\_/XXX\_/XXXXXXX\__/XXX\_/XXX\_/\_/XXXXXX