longj@lonex.radc.af.mil (Jeffrey K. Long) (04/28/91)
A friend and I were considering undertaking our first joint programming effort, and though that as a shake-down project, we would try and build a simple "hot-key" program that would allow one to swap between low-med resolution with the stroke of a key. I seem to remember reading something here in months past about the subject of changing resolutions within programs, and was wondering if someone who remebers the gist of the conversations would be willing to give me a brief summary of what was said then. Also, is there any way to force a resolution change WITHOUT a resulting reboot of the system. I mean, from desktop (med) to desktop (low) and vice-versa? Any help would be appreciated. -- ---------------------------------------------------------------------------- Capt Jeff Long Rome Laboratories, Griffiss AFB, NY longj@lonex.radc.af.mil (preferred) Network Design Laboratory jlong@cassiopeia.radc.af.mil (315)330-7751 or (DSN)587-7751
dmb@wam.umd.edu (David M. Baggett) (05/03/91)
In article <1991Apr28.014020.3838@lonex.radc.af.mil> longj@lonex.radc.af.mil (Jeffrey K. Long) writes: > >I seem to remember reading something here in months past about the subject >of changing resolutions within programs, and was wondering if someone who >remebers the gist of the conversations would be willing to give me a brief >summary of what was said then. I assume you mean, "Is there a way to change resolution such that GEM, AES, and VDI calls will work in the new resolutuion?" If so, the answer is no. Absolutely, positively do NOT bother trying to find a way to do this. It's completely impossible to accomplish without relying on undocumented locations in the ROM. Dave Baggett dmb%wam.umd.edu@uunet.uu.net
warwick@cs.uq.oz.au (Warwick Allison) (05/03/91)
>Also, is there any way to force a resolution change WITHOUT a resulting >reboot of the system. I mean, from desktop (med) to desktop (low) and vice-versa? Find out that, and you can also switch to hi-resolution without rebooting too. It can easily be done, but letting AES know is the problem (as you doubtlessly realise). When I write low res games, I write them on the mono-monitor, and just switch to the colour monitor to run them. All you have to do is set the trap vector for it to your own routine. You can force the mouse to be bounded correctly by re-initialising it (XBIOS). The problem does remain, how the get the AES to work properly. There are about a half dozen places in memory that have "640,400" or "639,399" stored, so there is probably no central, legal way to slap AES in the face to wake it up to a change in res. Ah well. Warwick. -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA.
bjoern@drdhh.hanse.de (Bjoern Kriews) (05/08/91)
From article <1991Apr28.014020.3838@lonex.radc.af.mil>, by longj@lonex.radc.af.mil (Jeffrey K. Long): > Also, is there any way to force a resolution change WITHOUT a resulting > reboot of the system. I mean, from desktop (med) to desktop (low) and vice-versa? No, there isn't. It's because the VDI/AES have to be initialized to the new video mode. On ROM Systems you can call Puntaes() to do a warmboot, there was also something about using shel_write to reinit, it used some -1 params, but I can't find it yet and don't know it it's documented or what. Greetings, Bjoern --- bjoern@drdhh.hanse.de = Bjoern Kriews / Stormsweg 6 / 2000 Hamburg 76 / FRG "gaaga mahwe Bjoern urgl ufzae Turbo-C bnub" (J. Willamowius)
cmedley@wam.umd.edu (Charles Henry Medley) (05/13/91)
In article <3094.05.91@drdhh.hanse.de> bjoern@drdhh.hanse.de (Bjoern Kriews) writes: >On ROM Systems you can call Puntaes() to do a warmboot, there was also >something about using shel_write to reinit, it used some -1 params, >but I can't find it yet and don't know it it's documented or what. > >Greetings, Bjoern Is Punt_aes called by TOS when the actual change from medium to low resolution is done? I am curious because it could help me in solving my problem with handling vectors during the change in resolution from "Set Preferences" and I've always wondered why punt_aes was still included in the ROM versions of TOS. Atari ST Internals (Abacus) never really mentioned any good uses for punt_aes.
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) (05/13/91)
In article <1991May12.234615.15781@wam.umd.edu>, cmedley@wam.umd.edu (Charles Henry Medley) says: >Is Punt_aes called by TOS when the actual change from medium to low resolution >is done? I am curious because it could help me in solving my problem with >handling vectors during the change in resolution from "Set Preferences" and >I've always wondered why punt_aes was still included in the ROM versions of >TOS. Atari ST Internals (Abacus) never really mentioned any good uses for >punt_aes. This is because there IS no use for Puntaes(). All it does is a warm boot without GEM IF AND ONLY IF the OS is in RAM. By the way: there is no legal method for accessories to change vectors. Thins like that belong into TSRs in the auto folder. ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (05/13/91)
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) writes: >By the way: there is no legal method for accessories to change vectors. >Thins like that belong into TSRs in the auto folder. That's why I'm looking for a officially approved way to intercept Trap #2. 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. The tricky part of this is waiting for the AES - how can you tell for sure? Because of this problem, I still have one accessory that re-vectors trap #2 - it's just much easier and seemed to be OK to me because this way I can be sure that AES has been started when my accessory comes up. If someone could show me a legal way for re-vectoring trap #2 in the AUTO folder, I could get rid of this accessory. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, West Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus Brod@wue.maus.de ----------------------------------------------------------------------
kbad@atari.UUCP (Ken Badertscher) (05/17/91)
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>
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (05/17/91)
kbad@atari.UUCP (Ken Badertscher) writes: >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... Yes, it keeps on ticking. But this is not my problem. The last time I checked I found out the following (at least I thought this was the case): You can install your own Trap #2 routines in the AUTO folder. AES or GDOS or whoever changes the vector, but is friendly enough to jump to the old routine in the Trap #2 vector after it has done its job. This is why your routine keeps on ticking. 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. As I'm thinking about it now (sorry for any mistakes, it's been some months that I thought about it the last time), this is just the standard problem of installation sequences. It's just that so many programs like to intercept Trap #2 - this makes it worthwhile to come up with a general solution for it. 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. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus Brod@wue.maus.de ----------------------------------------------------------------------
micro@imada.ou.dk (Klaus Pedersen) (05/20/91)
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
micro@imada.ou.dk (Klaus Pedersen) (05/21/91)
>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. Can you describe what you want to do? I know that I mixed it up in the last post (first in the chain/first installed)! To make it good I have included some, that does what you say you want, but what good is it, can you give an example? The routine I have included will every it is called check if it is the first routine on that vector chain. If it is not it will unlink it self, insert itself in the start of the chain, and then call the remaining routines in the chain. One funny thing is to install two of these, they really fight to get the first 'seat'. The code will only work if all routines uses the XBRA protocol. It is written using the shareware assembler, TurboAss, available at atari.archive. >>Claus Brod, Am Felsenkeller 2, Things. Take. Time. Klaus, micro@imada.ou.dk gemdos EQU 1 Ptermres EQU 49 ; Gemdos Cconws EQU 9 xbios EQU 14 Supexec EQU 38 ; xbios vector EQU $80+4*gemdos ; hook into GEMDOS v_bas_add EQU $044E first: bra.s install ********* XBRA HEADER ******************************************* ** The routine is AES/VDI ready, as it don't use any registers ** ** test VDI/AES in the 'SaveRegs' array. ** DC.B 'XBRA' ; XBRA identifier DC.B 'name' ; program ID DS.L 1 ; old vector x_hook: movem.l D0/A0-A1,SaveRegs lea x_hook-4(PC),A0 move.l (A0)+,-(SP) ; Push the address old routine cmpa.l vector.w,A0 beq.s all_ok ; I am the first! move.l A0,D0 ; I was not first and I want to be! movea.l vector.w,A0 ; - make me first NOW! xb_next: movea.l A0,A1 cmpi.l #'XBRA',-12(A1) ; Is 'XBRA' ok ? bne.s not_xbra ; NO -> PANIC!!! movea.l -(A1),A0 cmpa.l D0,A0 ; Is it me ? bne.s xb_next ; NO -> try next in chain... xb_inchain: move.l -(A0),(A1) ; unlink from the chain. move.l (A0),(SP) ; replace the return address on the stack move.l vector.w,(A0)+ ; reinsert first in the chain. move.l A0,vector.w ; NOW DO SOME REAL WORK movea.l #2,A0 bsr.s DO_THE_FUN all_ok: suba.l A0,A0 bsr.s DO_THE_FUN not_xbra: * auch... can't find myself! * * get the fool out of the auto folder!!!! * movem.l SaveRegs(PC),D0/A0-A1 rts SaveRegs: DS.L 3 DO_THE_FUN: adda.l v_bas_add.w,A0 addq.w #1,(A0) rts ******************************************************* ***************** INSTALATION ROUTINE ***************** install: pea take_vec(PC) move.w #Supexec,-(SP) trap #xbios clr.w (SP) ; Resident terminate move.l #($0100+install-first),-(SP) ; = Program length move.w #Ptermres,-(SP) trap #gemdos take_vec: lea x_hook-4(PC),A0 move.l vector.w,(A0)+ move.l A0,vector.w rts END
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (05/21/91)
micro@imada.ou.dk (Klaus Pedersen) 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. I must have been unclear at some point. Imagine a file selector replacement program for the AUTO folder. It must hook into TRAP #2, and its trap handler must become active _before_ the ROM AES. So this program must reside somewhere at the beginning of the XBRA chain, not at the end. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus Brod@wue.maus.de ----------------------------------------------------------------------
micro@imada.ou.dk (Klaus Pedersen) (05/23/91)
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. Yes I follow you now, I thought that the AES was as nice as the VDI. But it isn't - it eats all AES function calls (it don't link to the next in the Gem-vector-chain...). It replaces the trap #2 vector at least 2 times, this surpriced me, and the program that I tried to install. I tried to install a trap#2 routine that would install a AES handler when the AES had initilized itself. The first solution to this problem I thought about was to monitor the trap#2 vector for a non-XBRA routine, but AES unlinked the routines (I had a number of clones, that could be hooked in the vector, and shoot (w. RTS) if they failed). Then I thought that a OpenScreenWorkstation would tell when the AES was init. but a quick check showed that auto-folder programs also can open and close workstations, too - soo :-( Things would be much more easy if there was an exec_aes ;-) or a bit-vector where one could tell which part of the OS that had been init.'ed. (AND a bit-vector called >in_TOS< so that one could use Tos semi-reenterent) At this point I began to doubt that it could be done (legally)... So I tried to look at formdoit, but that did not help. Then I looked through all my docs, AES (see about), VDI (can't be used), Gemdos (likevise), Xbios (do), Bios - now here were something - setexc(), did AES enable it's own trap handler with this? A small program showed that it didn't, but there were something else, yes it enabled the evnt_critic vector with it!!! - heureka! Now - is it legal to assume that it will always be this way? Allan P.? Ken B.? - is it? You have not been very help-full on this subject, so I include a small program that uses the principe. Please flame this Allan and Ken, then tell how we are supposed to do it!! The program Form_Pop makes the dialogs pop-up under the pointer, real usefull for Julians R.'s BigScreen... Comments please! Klaus, micro@imada.ou.dk >Claus Brod, Am Felsenkeller 2, Things. Take. Time. ------ cut here --------- Turbo Ass - Again -------- gemdos EQU 1 Gem EQU 2 Bios EQU 13 Ptermres EQU 49 ; gemdos Cconws EQU 9 ; gemdos xbios EQU 14 Supexec EQU 38 ; xbios Setexc EQU 5 ; bios GemVector EQU $80+4*Gem ; hook into GEM longframe EQU $059E * SOME LINEA VARIABLES * MouseY EQU -$0258 MouseX EQU -$025A v_rez_hz EQU -$0C v_rez_vt EQU -$04 XBRAID EQU 'FPop' first: bra install **** THIS IS A ZOOMBIE THAT INSTALLS THE AES-HANDLER **** ** If when it have done it's job or it fails, it gives ** ** itself a silver bullet through the Heart (RTS) ** ******************' '*********************** ZombTrap EQU Bios DC.B 'XBRA' ; XBRA identifier DC.L XBRAID ; program ID DS.L 1 ; old vector Zoombie: move.l Zoombie-4(PC),-(SP) ; Push the address old routine MyHeart: move USP,A0 btst #5,4(SP) ; called from Supervisor- or User-mode? beq.s tst_funcs ; Parameter is on USER stack lea 6+4(SP),A0 ; Old (small) stack frame. tst.w longframe.w ; Is this running on a CPU beq.s tst_funcs ; with a long stackframe? addq.w #2,A0 ; -then add 2 more bytes. tst_funcs: cmpi.w #Setexc,(A0)+ ; Check the funcion number. bne.s Bullet cmpi.w #$0101,(A0) ; Is the desktop installing ErrorBoxes? bne.s Bullet ; NO -> then wait. lea GemHook-4(PC),A0 move.l GemVector.w,(A0)+ ; Put AES handler in the Chain. move.l A0,GemVector.w move.w Bullet(PC),MyHeart ; Give the Zoombie the silver Bullet Bullet: rts ********* THIS IS THE GEM-HOOK ITSELF ******************************** DC.B 'XBRA' ; XBRA identifier DC.L XBRAID ; program ID DS.L 1 ; old vector GemHook: cmp.w #200,D0 ; is it a call to the AES? bne.s not_AES ; NO -> call next move.l A0,SaveRegs movea.l D1,A0 movea.l (A0),A0 ; get pointer to control[] cmpi.w #54,(A0) ; call to form_center? beq.s FRM_CNTR ; YES -> Replace movea.l SaveRegs(PC),A0 not_AES: move.l GemHook-4(PC),-(SP) ; Push the address old routine rts ********** THIS IS THE NEW FORM CENTER ******************************* FRM_CNTR: movem.l D0-D3/A0-A2,SaveRegs movea.l D1,A0 movea.l 12(A0),A1 ; get int_out pointer. move.w #1,(A1)+ ; fill in fo_cresvd movea.l 16(A0),A0 ; get addr_in pointer movea.l (A0),A0 ; get pointer to the Object lea 16+4(A0),A0 ; get pointer to w,h in object movea.l LineA(PC),A2 move.w MouseX(A2),D0 ; Get x-pos of the pointer move.w v_rez_hz(A2),D2 ; Get width of screen moveq #4,D3 bsr.s CenterAndLimit move.w MouseY(A2),D0 ; Get y-pos of the pointer move.w v_rez_vt(A2),D2 ; Get height of screen moveq #21,D3 bsr.s CenterAndLimit movem.l SaveRegs(PC),D0-D3/A0-A2 rte CenterAndLimit: move.w (A0)+,D1 ; Read width/height of Object addq.w #8,D1 ; & add border. move.w D1,4(A1) ; write new length in width/height sub.w D1,D2 ; Calc. High-Limit of centered output lsr.w #1,D1 ; W = W/2 sub.w D1,D0 ; X = PX-W/2 cmp.w D3,D0 ; if (X - MIN bpl.s not_less ; < 0) move.w D3,D0 ; X = MIN; not_less: cmp.w D2,D0 ; if (X - MAX bmi.s not_bigger ; >= 0) move.w D2,D0 ; X = MAX not_bigger: move.w D0,(A1)+ ; Write X/Y-pos in int_out[] addq.w #4,D0 move.w D0,-6(A0) ; Write X/Y-pos into object rts LineA: DS.L 1 SaveRegs: DS.L 7 ******************************************************* ***************** INSTALATION ROUTINE ***************** install: pea take_vec(PC) ; Please Note: it is not a bug that move.w #Supexec,-(SP) ; this routine does NOT clean up the trap #xbios ; Stack... (it saves some bytes!!!) linea #0 [ Init ] ; Get pointer to LineA variables move.l A0,LineA pea InstString(PC) move.w #Cconws,-(SP) trap #gemdos clr.w (SP) ; Resident terminate move.l #($0100+install-first),-(SP) ; = Program length move.w #Ptermres,-(SP) trap #gemdos take_vec: lea Zoombie-4(PC),A0 move.l (4*ZombTrap+$80).w,(A0)+ move.l A0,(4*ZombTrap+$80).w rts InstString: DC.B 10,'Form-Pointer-Pop''s installed...',13,10,10,0 END
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) (05/28/91)
In article <1991May23.163442.12276@imada.ou.dk>, micro@imada.ou.dk (Klaus Pedersen) says: >Things would be much more easy if there was an exec_aes ;-) or a bit-vector >where one could tell which part of the OS that had been init.'ed. >(AND a bit-vector called >in_TOS< so that one could use Tos semi-reenterent) There is an exec_aes. It's called exec_os! >The program Form_Pop makes the dialogs pop-up under the pointer, real usefull >for Julians R.'s BigScreen... The new `BigScreen 2' (a commercial product) installs a cookie which contains information about the visible part of the screen. Application and library writers can use this to `really' center their dialogues. ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (05/28/91)
ONM07@DMSWWU1A.BITNET (Julian F. Reschke) writes: >There is an exec_aes. It's called exec_os! Don't forget to mention that Allan Pratt recommended not to use exec_os because it is due to change sometime in the future. I wouldn't have started this discussion if I could legally use exec_os. ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ----------------------------------------------------------------------