Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!brl-adm!rutgers!dayton!viper!john
From: john@viper.UUCP (John Stanley)
Newsgroups: comp.sys.atari.st
Subject: Re: Vertical Blank Interrupts
Message-ID: <689@viper.UUCP>
Date: Tue, 17-Mar-87 17:30:00 EST
Article-I.D.: viper.689
Posted: Tue Mar 17 17:30:00 1987
Date-Received: Thu, 19-Mar-87 03:15:30 EST
References: <741@eneevax.UUCP>
Reply-To: john@viper.UUCP (John Stanley)
Distribution: world
Organization: DynaSoft Systems
Lines: 66
Keywords: Bios XBios Gem ROM Interrupt VBI Bugs
Summary: Long explanation of non-reenterant bios problem

In article <741@eneevax.UUCP> iarocci@eneevax.UUCP (Bill Dorsey) writes:
 >I've been doing a lot of work involving use of the vertical blank interrupts
 >recently, and have noticed certain annoying behaviors.  I'd appreciate com-
 >ments or suggestions related to either of the following:
 >
 > [_description of details deleted_]
 >
 >The other question I have regarding VBIs is this:  I want to use a VBI to
 >monitor some event, and then after that event occurs, temporarily suspend the
 >current process and execute some code that takes a bit of time.  Unfortunately,
 >every time I do this, the system crashes very quickly.  Bios calls are sup-
 >posed to be re-entrant to only three levels, and my code does make a Bios
 >call in the interrupt section, so I thought maybe this was the problem.
 >
Well, they are supposed to be re-enterant, but it doesn't work right for
bios calls from within an interrupt routine.

  I had lots of fun tracking this roblem in a program I wrote which also
tried to make bios/xbios/gem calls from within an interrupt...  I tracked
the problem for 4 days thru the bios ROMS.  This is one of the problems
I hope they fix in the new ROMs.  (Note to Atari:  If you guys haven't
come up with a solution for this, contact me....)

  There is a bug in how trap 13 and trap 14 (bios and xbios) are handled.
As you pointed out in your message, there is an area used to save registers
while processing a trap call.  The code that does the save and restore was 
written (aparently) by someone with little or no experience dealing with 
an interrupt driven system.

  The code in question consists of 10-20 lines of assembly.  Since the
interrupts are not disabled and the code is not written in a way that
would allow interrupts to occur without causing problems, you eventualy
end up with a VBI or some other interrupt occuring in the middle of this
save or restore code.  If you then try to make a call to the bios (or to
any GEM function which uses the bios) the registers saved for your call
overwrite some (randomly 0-15 of them) of the registers saved for the
call being made at the time of the interrupt.  When your interrupt call
returns, the save/restore register bios routine finishes it's job and
the system continues on with no knowledge that the registers saved are
incorrect.  When it trys to return to the function that called the bios
in the 1st place, the incorrect registers are "restored" causing lots of
problems all over the place depending on the program being run...

  One other possibility is that the bios calls you were making took too
much time to return.  There are a few places in the VBI code I doubt will
work very well if you call them a second time before they return from a
previous interrupt...

  Hope this explains the problems you (and I) have been having.  As a
general rule, "Don't make any BIOS/XBIOS/GEM calls from an interrupt
routine.".  There's almost allways a way to get things done without
using them (Note: I said "ALMOST".)  So far, I've been able to use
several tricks to get things done when I need to.  Hope you can too..

 >.......  Anybody got any suggestions,
 >or will I have to write a multi-tasking kernel just to monitor an i/o port?
 >Sure seems like overkill!

Sure would be.  Since Beckemeyer has already done just that, perhaps
you would want to try using his multitasking system before you go to
all the trouble of writing your own...

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john