[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::atarist

Title:	Atari ST, TT, & Falcon
Notice:	Please read note 1.0 and its replies before posting!
Moderator:	FUNYET::ANDERSON

Created:	Mon Apr 04 1988
Last Modified:	Tue May 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1433
Total number of notes:	10312

599.0. "AES<->TRAP<->BIOS" by ZUR01::BOLLIGER () Mon Sep 18 1989 04:38

    			( From Trap to AES and back )
    Could someone give me a solution with this Problem
    
    I wrote a Program in Assembler that intercept the BIOS Conout function
    within that Program i call the AES function FORM_ALERT after
    returning from The Form_alert i got BOMBS..
    is it possible to Call AES from a TRAP ??
    if yes wat i have to do
    somebody tall me that AES and BIOS is not Reentrant ??
    
    					Thanks Fred

T.R Title User Personal
Name Date Lines

599.1 PRNSYS::LOMICKAJ Jeff Lomicka Mon Sep 18 1989 11:21 26

T.R	Title	User	Personal Name	Date	Lines
599.1		PRNSYS::LOMICKAJ	Jeff Lomicka	`Mon Sep 18 1989 11:21`	26
	I can't say exactly what is wrong, but for starters, you are already in supervisor mode when the Cconout trap routine is executed, so you need to watch that you don't overrun the supervisor stack when executing another trap. Second, there IS a low limit on this kind of re-entrant behavior, I read this somewhere, and think it is "3". AES may already be at the limit. By starting out in Cconout, you may put it over the limit. Personally, I never would have considered such at thing - I would have dismissed calling AES from a trap as unlikely to work under any conditions. Pleae let me know if you get it to work, as I would find it useful. One thing you might try is, from the Cconout trap routine, alter the process stack to appear as if you have JSR'd into a process-level Cconout routine, and then taken the trap. You then RTI from the trap routine into the user mode routine of your choice, which can do AES and VDI to your heart's content, and then RTS back to the original stream of execution. You have to be careful, and a little clever, but this method should work. (A similar trick is used on VAX/VMS in VALID's GED in order to trap all the Pascal Writeln's at AST level, and display the resulting text in the graphics window. Yes, it an ugly hack, but it does work.)

I can't say exactly what is wrong, but for starters, you are already in
supervisor mode when the Cconout trap routine is executed, so you need
to watch that you don't overrun the supervisor stack when executing
another trap.

Second, there IS a low limit on this kind of re-entrant behavior, I
read this somewhere, and think it is "3".  AES may already be at the
limit.  By starting out in Cconout, you may put it over the limit.

Personally, I never would have considered such at thing - I would have
dismissed calling AES from a trap as unlikely to work under any
conditions.   Pleae let me know if you get it to work, as I would find
it useful.

One thing you might try is, from the Cconout trap routine, alter the
process stack to appear as if you have JSR'd into a process-level
Cconout routine, and then taken the trap.  You then RTI from the trap
routine into the user mode routine of your choice, which can do AES and
VDI to your heart's content, and then RTS back to the original stream
of execution.  You have to be careful, and a little clever, but this
method should work.

(A similar trick is used on VAX/VMS in VALID's GED in order to trap all
the Pascal Writeln's at AST level, and display the resulting text in the
graphics window.  Yes, it an ugly hack, but it does work.)