Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!mailrus!ames!amdcad!sun!imagen!atari!apratt
From: apratt@atari.UUCP (Allan Pratt)
Newsgroups: comp.sys.atari.st
Subject: Re: Mfpint()
Message-ID: <1359@atari.UUCP>
Date: 22 Feb 89 18:05:58 GMT
References: <8902140121.AA03228@ucbvax.Berkeley.EDU> <825@per2.UUCP> <336@wn2.sci.kun.nl>
Reply-To: apratt@atari.UUCP (Allan Pratt)
Organization: Atari (US) Corporation, Sunnyvale, California
Lines: 35

In article <336@wn2.sci.kun.nl> sommel@wn2.sci.kun.nl (Ron Sommeling) writes:
> In article <825@per2.UUCP>, dag@per2.UUCP (Daniel A. Glasser) writes:
> > 
> > Although, technically, you can call BIOS and XBIOS functions from interrupt
> > level routines, it is not a good idea in general.  It is better to set flags
> > for the application "user-mode" routines to deal with.
> 
> No, you can't safely call any BIOS or XBIOS function from within an
> interrupt.

That is not the case.  You CAN call BIOS or XBIOS routines from
interrupts.  The way to do it is documented (in the documentation, of
all places, not the disassembly!).  You subtract 46 ($2e) from the
system variable 'savptr' which is at $4a2.  THEN you use the TRAP
instruction.  When the trap returns, you add $2e to savptr again. 

With this approach, one can write a BIOS call in C, because when the
dispatcher calls the [X]BIOS function, the arguments are right on the
stack, just as virtually all C compilers expect them to be.  A couple
of BIOS calls *are* written in C, notably Rwabs().

I don't know that I'd have made this decision if I'd designed the BIOS,
but it does work, and it *is* reentrant, if you do what the
documentation says to do.

THIS IS NOT AN ENDORSEMENT OF USING BIOS FROM INTERRUPT LEVEL.  If you
find your program is doing that, re-think your program.  There are not
very many reasons to call BIOS like that, and a number of reasons not
to: speed is the most important.  Furthermore, NEVER ATTEMPT PRINTER OR
DISK I/O FROM INTERRUPT LEVEL, because aside from the time it will take,
timers and things aren't running. 

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt