Path: utzoo!utdoe!generic!pnet91!ericmcg
From: ericmcg@pnet91.cts.com (Eric Mcgillicuddy)
Newsgroups: comp.sys.apple2
Subject: Re: Orca/C/M...Ack!
Message-ID: <530@generic.UUCP>
Date: 21 Feb 91 11:00:06 GMT
Sender: root@generic.UUCP
Organization: People-Net [pnet91], Etobicoke, ON
Lines: 54

>Well, if you're installing it with SetTSPtr and SetDefaultTPT (encouraged
>if your installer runs at boot time) then you should always expect two RTS's
>on the stack (as normal tool functions are required to).
>
>Todd Whitesel
>toddpw @ tybalt.caltech.edu

Volume 3 says that applications should never make this call. An Init is an
application, ending with RTL, therefore an Init should never make
SetDefaultTPT. Or so my reasoning went at the time. Regardless ViM works fine
without it and I require the option to restore the old FPT pointer if the user
requests it (for compatibility reasons), this should only occur in the Finder
and should not be dangerous.

The two RTLs on the stack were picked up using GSbug (why two?) and it just a
matter of updating a few global EQUs to get the correct parameters. NewHandle
was a special case, the other five patches did their stuff before passing
control to the original code, NewHandle did its stuff after (Basically adding
the Handle to the LRU queue). What I had to do was extract the original return
address from the stack, save it, change it to return to my routine, make the
call and then put the original return back. I made two mistakes. First I
forgot that the return from original NewHandle call would not leave any return
addresses on the stack (having returned to what it thought had called it), so
I ended up overwriting the Handle I wanted saved and returned with the
original return address. Secondly, I save the P and B registers before doing
my stuff, but I confused the size of the B register with the D register and
pulled an extra byte from the stack (it's a long story). So not only did I
eradicate the Handle that the call was expected to return, I corrupted the
address that was to be returned to!!!   Ever have one of those month's?

Anyhow, that is all in the past. I have now have it installed in my system and
it seems to mostly work. The only program that I have that does not work with
it is Proterm, I suspect that this is due to the way it grabs the GS's memory.
I can get Proterm to operate correctly by first running Mousewrite (weird but
true). All of my GS specific programs work with it active, however I still get
Out of Memory with Halls of Montezuma and I doubt any of the others take real
advantage of the concept. In order for a memory segment to be swapped out, it
must be position Independent, Unlocked and not in Bank 0. I think very few
segments meet all three criterio.

I will be working on a demo, something that just creates a few megs of memory
segments and accesses them randomly, do demonstrate that a programmer can
create a very large program without having to worry about overlays or the
Segment Loader overhead. Assuming that they follow rules at any rate.

There is one problem in that after several applications have been run, it will
drop into the monitor (or GSbug in my case). I think that this is due to too
small a workspace for the LRU queue. I also want to replace the cheesy
Applesoft installation program.

Wish I knew what the problem with Proterm was.

UUCP: bkj386!pnet91!ericmcg
INET: ericmcg@pnet91.cts.com


Brought to you by Super Global Mega Corp .com