Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!sun-barr!newstop!exodus!appserv!sun!imagen!atari!kbad
From: kbad@atari.UUCP (Ken Badertscher)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: Force Desktop Res Change?
Message-ID: <2941@atari.UUCP>
Date: 16 May 91 19:41:29 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>
Organization: Atari Corp., Sunnyvale, CA
Lines: 56

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

|There seems to be no easy way to do this with an AUTO folder program -
|AES overwrites any changes, and so you have to write a TSR that waits
|for AES to come up and then re-vectors trap #2.

Nope.

I don't know where this rumour came from, but it's been flying around
for some time now, and I've run into it about 3 times in the past month,
so it's time to start spreading facts.

Nobody should be touching trap #2 on a res change.  Think about it for
a minute: if trap #2 got taken every res change how could GDOS possibly
work?

Assemble the following, put it in your auto folder, and change res a
couple dozen times.  You'll see that the trap #2 counter in the upper
left corner of the screen keeps on ticking...

; TAKE2.S - count trap #2's, even after res change.

trap2vec    = $88
_v_bas_ad   = $44e

start:
    pea     take2(pc)
    move    #$26,-(sp)
    trap    #14         ; Supexec(take2)
    addq    #6,sp

    clr.w   -(sp)
    move.l  #($100+fin-start),-(sp)
    move.w  #$31,-(sp)
    trap    #1          ; Ptermres(0,size)

take2:
    lea     save2(pc),a0
    move.l  trap2vec,(a0)+
    move.l  a0,trap2vec
    rts
    
save2:
    dc.l    0
do2:
    move.l  _v_bas_ad,a0
    addq.l  #1,(a0)
    move.l  save2(pc),a0
    jmp     (a0)
fin:
    .end

-- 
   |||   Ken Badertscher  (ames!atari!kbad)
   |||   Atari R&D System Software Engine
  / | \  #include <disclaimer>