🚀 go-pugleaf

In article <892@a.lanl.gov> wxh@a.lanl.gov (Billy Harvey) writes:
>Several people have said you can have either a reset-proof _or_ a
>resizeable ram disk, but not both.  Could it work like this:
>The reset proof ram disk would be by the normal bootup method of
>telling TOS a new top of memory.  The resize ability would not
>necessarily have to be able to occur within a program, since many
>allocate all free memory, but why shouldn't it be able to occur at
>the desktop level?

  Because that limits its uses. Imagine the wonderful benefits you can get if
you could run a resizable RAMdisk from within, say, ARC.TTP. You're
uncompressing a package, and send all of the bits into the RAMdisk. As the
RAMdisk runs out of room, it resizes itself until it reaches the limits of your
ST's memory. Unfortunately, from the technical reason cited above, this can't
be done.

>Somehow TOS would have to be forced to recognize
>a new top of memory without rebooting.  Does anyone know if thats a
>doable thing?  It wouln't even necessarily have to be through a
>legal TOS vector, the program would just have to check which version
>of TOS it was running under.  It would certainly be handy.

  Sounds dangerous to me. The last thing I would want is to write a utility
that becomes a menace under a different version of TOS. What lessons did we
learn from improperly-written ST programs not running on the Mega ROMs?

						--R.J.
						B-)

 =============================================================================
                 Disclaimer: This message was written with my authorization
      # ## #
      # ## #     Mailing address: rjung@nunki.usc.edu
     ## ## ##          (It's easier to just use the reply function, tho)
  ####  ##  ####