U46050@UICVM.BITNET (JOHN ZAFIRIS) (10/18/88)
Hello all. I have run accross a bit of a problem in shutting off
interrupts on the ST and surviving when I turn them back on. The
program I am writing depends on some VERY tight timing and whenever
something interrupts the cpu, the timing goes "off" and I get garbage
for data.
The routine is entirely in machine code. I shut off all interrupts by:
move.w #$2700,sr. This works great and my program does its thing without
any problem but when turning the interrupts on again by: move.w #$2000,sr
or move.w #$2300,sr and returning to the shell, the machine freezes up.
No mouse, no keyboard response, no blinking cursor.
Since this did not work, I decided to just divert all the interrupt vectors:
IPL2, IPL4, and IPL6 as well as the 192 vectors starting at $100. I pointed
them to a dummy RTE within my program before running the critical routine and
restored them to their original values before exiting. My routine again worked
flawlessly (I relaxed the timing enough to tolerate this minor exception
processing) but again when returning to the shell, the machine was frozen.
It is interesting to note that this approach actually worked the first few
times I tried it but somehow cripples mouse clicking sometimes when it doesn't
completely freeze the machine.
Since this did not work, I took yet another tack: disable the HBL and the VBL
interupts and handle the rest of the interrupts direcly within the MFP 68901.
I first assumed that the "Software End-of-interrupt" mode was causing trouble
so I had all the interrupts clear registers 8 & 9 (ISRA,ISRB) of the MFP just
before executing RTE. This did not work so I disabled all 16 interrupt sources
within the MFP by clearing registers 4 & 5 and restoring their original values
before exiting: again no go.
Needless to say, I have still to find out what the problem is. I am
contemplating putting a switch on the three 68000 interrupt lines to pull them
all high manually and initiate the routine from a polled port and not have to
find a solution but that is both extreme and dangerous (I only have one ST) not
to mention that it should be unnecessary with the interrupt mask.
HELP...HELP...What the H*LL is going on?!?!?!?!?!
I hope I have overlooked something obvious. If someone sees it please tell me
what it is. I'll practice blushing to be ready for the innevitable.
thanks... ...John
PS. I have also shut off just the VBL (via all routes: semaphore, vector, mask)
but without any luck.
===============================================================================
Do you sometimes get a feeling electronics run solely on soular power???
===============================================================================uace0@uhnix2.uh.edu (Michael B. Vederman) (10/19/88)
First of all, you must do something like this:
move.w sr,-(a7)
ori.w #700,sr
(your code)
move.w (a7)+,sr
In actuality, you should probably do something like:
move.w sr,-(a7)
ori.w #700,sr
movem.l d0-d7/a0-a5,-(a7)
(your code)
movem.l (a7)+,d0-d7/a0-a5
move.w (a7)+,sr
To protect any possible register changes. I would also be sure you are not
screwing up the stack pointer which almost sounds possible. You should not
mess with the status register except by oring it to mask out interrupts, but
mostly you must restore its previous value. You might also need to check
whether you are in super or user mode when you enter your code, so you know
which stack to use...
- mike vederman
--
for (;;) : Use ATARINET, send an interactive
do_it(c_programmers); : message such as:
: Tell UH-INFO at UHUPVM1 ATARINET HELP
University Atari Computer Enthusiasts : University of Houston UACE) (10/19/88)
In article <8810181052.AA28587@ucbvax.Berkeley.EDU> U46050@UICVM.BITNET (JOHN ZAFIRIS) writes: >Hello all. I have run accross a bit of a problem in shutting off >interrupts on the ST and surviving when I turn them back on. [ Deleted text] >The routine is entirely in machine code. I shut off all interrupts by: >move.w #$2700,sr. This works great and my program does its thing without >any problem but when turning the interrupts on again by: move.w #$2000,sr >or move.w #$2300,sr and returning to the shell, the machine freezes up. >No mouse, no keyboard response, no blinking cursor. [ Other futile attempts deleted ] Of course the first thought I have is that "The routine entirely written in ML" might be your problem. Try replacing it with a big loop that takes ~5 Minutes. Why 5 Minutes ? Why not... Anyway there shouldn't be any problems with short uninterrupted code-pieces. To be really safe from any interference. I'd suggest that you pretty much clean the MFP (sp?) and unmask all IRQs. Restore only the mask and forget about restoring the pending IRQs. Ignore them. I assure you: It can be done. /----------------------------------------------------------------\ // \\ | Georg Wallmann (Natuerlich!) cgw%trillian.irb@unido.uucp | | ...uunet!unido!cgw |