Michael J. Mahon wrote:
mdj wrote:On Aug 29, 9:46 pm, David Schmenk <dschm...@YUCH.gmail.com> wrote:Thanks, I'll look more into the STARTUP protocol. Which program selector do you use that implements it? I already parse command line arguments at the "main class:" prompt, so it shouldn't be a stretch. As for quits, I'm being a little conservative since I blow away the ProDOS quit code for my own uses. It will get worse when I use more reserved ProDOS memory on a 128K machine ;-) Not sure how well ProDOS will recover after my mucking about.I use ProSEL, but they all follow the same technique AFAIK. I assume it's a simple matter of rescanning the input buffer at launch. BASIC.SYSTEM uses this technique to allow launching BAS and BIN files from a selector...I thought that was done by planting the path at a certain spot a few byte after $2000 and marked as "present" by a $EE $EE (or something) sentinel, followed by a length byte and the STARTUP path. The path is poked into the slot by the selector before handing over control.
I think the ProDOS tech ref or one of the tech notes describes this. Should be pretty straight forward.
I see what you mean with the quit code... Perhaps you could copy it to the heap area and trash it only when memory becomes tight? As for 128k systems, that's nice and easy. As long as /RAM is connected when your SYS program starts, you can disconnect it then reclaim the entire aux bank for your own purposes. It's only when /RAM is disconnected at launch that the Aux LC reserved area must be respected.Maybe the Quit code should restart the Java environment after an application runs... -michael AppleCrate II: An Apple II "blade server"! Home page: http://members.aol.com/MJMahon/ "The wastebasket is our most important design tool--and it's seriously underused."
This makes a lot of sense. I can reload my loader without having to worry which parts of ProDOS I destroyed ;-)
Dave...