Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!dkuug!diku!ballerup
From: ballerup@diku.dk (Per Goetterup)
Newsgroups: comp.lang.pascal
Subject: Re: Problems with timer interrupts
Message-ID: <1991Jan6.150656.8281@odin.diku.dk>
Date: 6 Jan 91 15:06:56 GMT
References: <25403@adm.brl.mil>
Sender: news@odin.diku.dk (Netnews System)
Organization: Institute of Computer Science, U of Copenhagen
Lines: 67

CDCKAB%EMUVM1.BITNET@cunyvm.cuny.edu ( Karl Brendel) writes:

=> In article <1991Jan4.145541.17737@odin.diku.dk>, I wrote:

=> ...
=> >        I'm having some rather weird problems with a program of mine
=> >which needs to get something updated on the screen no matter what
=> >else the program might be doing.
=> >        I'm using interrupt 1C (User Timer Tick) to call my procedure which
=> >by the way DOESN'T call DOS (common error) - it only modifies the screen
=> >memory.
=> >        The problem is not to get it to work (it does) but what
=> >happens next. I start it up by saving the old vector then
=> >re-assigning it to point at my handler (procedure). This does indeed
=> >work and the screen get modified as it should while my is running
=> >happily along. So far so good. Then something might happen because
=> >sometimes the computer simply stops in the middle of the program and
=> >lock up (refusing warm-boots), other times it runs all the way to
=> >
=> [remainder deleted]

=> Your description (sans code) doesn't indicate whether you are
=> providing for a repeat of the interrupt while you are servicing it.
=> I.e., if you are still inside your routine when another 1C or 08
=> call occurs, what happens? While I don't think this question
=> addresses the problem with lockups that occur after exiting your
=> program, it may yield clues to some of the other behavior you
=> describe.

I think you're right Karl. I didn't provide for the possibility that another
interrupt might occur while I was servicing the previous interrupt, thus
creating a recursive routine that fast messed the stack up completely.

One of the answers I got indicated this and I've tried it. Now everything
runs, if it runs, because now the program either will run flawlessly until
(intended) termination when it (again) freezes the machine, or it will crash
on my very first append-to-pointer-chain call. This last action ONLY happens
when run from an EXE-file (as far as I've seen).

I've tried to see if I somehow didn't reach the point where I reset the
vector to its old value, by simply omitting the reset to see what happens,
and still the machine crashed at the end of the program, only now the
interrupt kept on running, updating the screen! - The machine still refused
warm-boots! - What happens here?

I've created a small test program that, using a simple clock, tests the
various solutions I get or think of. Unfortunately I didn't bring it with me
today, but I can provide it if nessesary.

I've also got suggestions (from elsewhere) to use interrupt 16h (keyboard
I/O) which gets called every time the machine isn't too busy doing hard CPU
or disk work. Anybody got expirences in using this???

Also, when should I call the old service routine from within my new one? -
First, last or in the middle?

	All help very appreciated!

		Per.

PS: I'm using an IBM PS/2 model 80 (386) running PC-DOS 3.30 and TP 6.0

-- 
| Per Gotterup                        | "The most merciful thing in the    |
| Student, DIKU (Dept. of Comp. Sci.) | world, I think, is the inability   |
| University of Copenhagen, Denmark   | of the human mind to correlate all |
| Internet: ballerup@freja.diku.dk    | its contents."  - H.P. Lovecraft - |