Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!uwvax!oddjob!mimsy!eneevax!iarocci
From: iarocci@eneevax.UUCP
Newsgroups: comp.sys.atari.st
Subject: Vertical Blank Interrupts
Message-ID: <741@eneevax.UUCP>
Date: Thu, 12-Mar-87 20:32:19 EST
Article-I.D.: eneevax.741
Posted: Thu Mar 12 20:32:19 1987
Date-Received: Fri, 13-Mar-87 23:40:45 EST
Reply-To: iarocci@eneevax.UUCP (Bill Dorsey)
Distribution: world
Organization: Amgem, Inc.
Lines: 42

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:

First, I install a vertical blank driver at the address pointed to by vblqueue
($456).  I check for the first vector in the list that is NULL before install-
ing it.  This is usually the first one when called from the auto folder, acc-
ording to my debug information.  Then, at some point, the system randomly
writes its own vector right on top of mine.  Great!

Well, I set the program to start checking for an empty slot with the second
entry in the vbi queue next.  Now, my handler survives the boot process.  Un-
fortunately, now I can no longer run Degas Elite!  Apparently it wants the
second entry in vblqueue for something.  In desperation, I set my routine to
start scanning for an unused entry at the end of vblqueue, searching backward.
Everything seems to work now, but I'm still worried about future compatibility.

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.

Flipping through The Guide in the hopes of finding a solution to my problem,
I noticed a variable called savptr ($4a2).  Apparently this is where the OS
saves registers during Bios calls.  I thought I remembered reading somewhere
that the three-level re-entrancy of Bios calls was due to there only being
sufficient space for three sets of register saves.  So, I created a nice big
array (4k), and set savptr to point to the array.  Well, the system still
crashes, although not quite as easily as before.  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!

-------------------------------------------------------------------------------
| Bill Dorsey          'Imagination is more important than knowledge.'        |
|                                            - Albert Einstein                |
|     'He who has imagination without learning has wings and no feet.'        |
|                                            - Joubert                        |
| ARPA : iarocci@eneevax.umd.edu                                              |
| UUCP : [seismo,allegra,rlgvax]!umcp-cs!eneevax!iarocci                      |
-------------------------------------------------------------------------------