Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!uupsi!sunic!dkuug!imada!micro
From: micro@imada.ou.dk (Klaus Pedersen)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Force Desktop Res Change?
Message-ID: <1991May19.180509.18398@imada.ou.dk>
Date: 19 May 91 18:05:09 GMT
References: <1991Apr28.014020.3838@lonex.radc.af.mil>  <3094.05.91@drdhh.hanse.de> <1991May12.234615.15781@wam.umd.edu> <91133.112834ONM07@DMSWWU1A.BITNET> <1991May13.121912.16552@informatik.uni-erlangen.de> <2941@atari.UUCP> <1991May17.115339.20960@informatik.uni-er
Sender: news@imada.ou.dk (USENET News System)
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Lines: 46

csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) writes:

>But this also means that I don't have any chance to do
>parameter fiddling _before_ AES or VDI do their job unless I wait
>for AES to come up, and then install my own Trap #2 handler.

Why don't you check the trap #2 XBRA chain, before you run the
patch routine (in the patch routine)? If you isn't the last, then
remove yourself from the XBRA chain and insert again in the end.
-before the the first non-XBRA routine (hopefully TOS). 
(you don't have to search all the chain, but only from the 'link'
 address in your XBRA header, this reduces the searching time and
 the risk that some fool takes the trap (non-XBRA)).
 
I feel like saying this one more time : XBRA!!!

>To open another thread of discussion: Allan Pratt mentioned the
>possibility of virtual memory support in TOS, including protection
>mechanisms. The XBRA standard comes to my mind: To find out if
>my own program has already been installed, I have to wander through
>other processes' memory. I wonder if this could cause severe
>problems in some upcoming VM, multitasking TOS.

A TSR is not a process! It is a part of the exception handling system.
I guess that the Supervisor have the right to do anything! But that
programs that run in usermode will have problems if they access outside
the pages that they have been assigned!
Programs that stay resident is special, they have to be in memory at all 
times because they are not processes! Normally in VM systems the processes 
are assigned addresses that start from some fixed address (fx 0) to implement 
"allocate on access"! These two things are conflicting, because TSR's start
their life as a Process!
Somehow the TSR's memory have to be given to the System (so that it become
part of the operating system). Because a TSR have to call the next Exception
handler, all TSR (and therefor Processes) have to be allocated unique 
addresses!
And because programs enter and leave Supervisor mode, they have to have
the same address translation table! (or at least the User-address translation
table have to contain a subset of the supervisor mode ditto).

I hope that Atari comes up with some real radical thinking, so that we
can have VM.
 
>Claus Brod, Am Felsenkeller 2,			Things. Take. Time.

Klaus, micro@imada.ou.dk