Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!ucla-cs!rutgers!mcnc!decvax.dec.com!bacchus.pa.dec.com!rust.zso.dec.com!shlump.nac.dec.com!shodha.enet.dec.com!elvira!ridder
From: ridder@elvira.enet.dec.com (Hans Ridder)
Newsgroups: comp.sys.amiga.tech
Subject: Re: Micro Timing Critical sections HELP!
Message-ID: <1687@shodha.enet.dec.com>
Date: 20 Sep 90 17:21:30 GMT
References: <4934@uqcspe.cs.uq.oz.au>
Sender: news@shodha.enet.dec.com
Organization: Digital Equipment Corporation, Customer Support Center
Lines: 72

In article <4934@uqcspe.cs.uq.oz.au> thyssen@batserver.cs.uq.oz.au writes:
>   I calculated that the `E' line should be runing at .715Mhz (1/10th
>of cpu clock rate) and physical measurments (a stop watch over ~20mins)
>give a figure of .709 +/- .001 Mhz (3 measurements were made).

Since it looks like you are down-under, are you doing this on a PAL
Amiga?  I don't remember the exact frequency, but I think PAL Amigas run
at 7.09MHz (instead of 7.15MHz), giving an E clock of .709MHz.  This is
well documnted in the 1.3 RKM's, I believe.

>   Timing a fixed loop of code (see below) however produced varing
>results which I beleave is due to the interupt handling of the CPU.
>
>IE with the full screen visible this timed to about 42440 +/- 10 `E' ticks.
>Moveing the screen then so only the title bar was showing (while timing)
>produced a much lower value (varing a good deal) of 40200 +/- 60 `E' ticks.

My first guess is that your code was running in Chip ram, thus
contending with screen (and other) DMA.  It would be best if you could
run in Fast ram (if you have any).

Someone else posted about having troubles with repeatable timing,
although I think he was having the timer set an interrupt, and found
that something in the system was disabling interrupts (Disable()) for a
long time, so his interrupt response time was erratic.  (Is that a
run-on sentence, or what?)

>QUESTIONS :-
> 1)  What is the differance bettween Disable-Enable
>   and Forbid-Permit exec library calls?

Put simply, Disable() shuts off all interrupts to the processor.  This
call should only be used when you want to change things which are
accessed by interrupt routines.  Forbid() just stops task switching.
This call should be used when changing things other *tasks* (or
processes) access.  Beware that a Forbid() can be "broken" (i.e. another
task might run) if you do anything which causes a Wait().  You probably
don't want to do any DOS I/O (Read(), printf(), etc.) during a Forbid().

> 2)  How do you blank the screen?

I'm not sure what you mean here.  If you just want to "shut off" the
display DMA, there is a macro (in the graphics includes, I think) called
OFF_DISPLAY, or something like that.  Be sure to turn the display back
on when you're done.

> 3)  Is there any other interupts which can be disabled? How?

The Amiga is *full* of interrupts.  If you don't want anything else to
bother you, use Disable().  Note that the system time (and probably
other things) will stop during a Disable(), so do this sparingly and
probably not in production code.

> 4)  Under the above can memory still be allocated/deallocated - Important?

If you asking if memory can be allocated/deallocated during a Disable(),
sure.  The only time you should *not* do any memory
allocation/deallocation is *inside* an interrupt handler.  (Because you
could have interrupted someone elses allocation/deallocation.)

> 5)  Any other comments.

Sounds like you need to get/read the Rom Kernel Manuals, published by
Addison-Wesley.

>  Anthony Thyssen - (Dragon Computing!)         thyssen@batserver.cs.uq.oz.au

-hans
------------------------------------------------------------------------
  Hans-Gabriel Ridder			Digital Equipment Corporation
  ridder@elvira.enet.dec.com		Customer Support Center
  ...decwrl!elvira.enet!ridder		Colorado Springs, CO