Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!utgpu!watserv1!watdragon!spurge!ccplumb
From: ccplumb@spurge.uwaterloo.ca (Colin Plumb)
Newsgroups: comp.sys.amiga.tech
Subject: Questions about QBlit(), etc.
Summary: Can QBSBlit() squeeze between one bltnode's blits?
Message-ID: <1990Dec17.075228.15068@watdragon.waterloo.edu>
Date: 17 Dec 90 07:52:28 GMT
Sender: daemon@watdragon.waterloo.edu (Owner of Many System Processes)
Organization: University of Waterloo
Lines: 61

The Libraries & Devices RKM (1.3) says that when your bltnode.function
returns nonzero, it is called again "the next time the blitter is done
until you finally return 0."  But it also says that "Beam synchronization
takes precedence over the simple FIFO.  This means that if the beam sync
matches, the beam-synchronous blit will be done before the non-synchronous
blit in the first position in the queue."  What I wonder is, when my
bltnode.function is called again, can I assume the blitter registers
(modulos, first & last word masks, blitter control - all those things
that don't change between bitplanes) are as I programmed them last or
do I have to reload them?  I.e. can QBSBlit preempt within a bltnode, or
only between them?

I haven't disassembled the relavent functions (the blitter interrupt
handler and the QBlit routine) enough to answer this to my satisfaction,
and I'll have to take 2.0 apart as well to get a de facto answer.  A
de jure one would be even better.

(By the way, the code contains examples of

movem.l	d0-d1/a0-a1,-(sp)
bsr somefunction
movem.l	(sp)+,d0-d1/a0-a1
movem.l	d0-d1/a0-a1,-(sp)
bsr someotherfunction
movem.l	(sp)+,d0-d1/a0-a1

is that really necessary?)

Also, what are the register conventions for the bltnode.function?
Preserve all but A0/A1/D0/D1?  Or the interrupt convention of A5 is
your is_Code (it is, disassmebly reveals) and it and A6 is scratch
(disassembly shows it isn't ExecBase, and it seems to need to be
preserved, but I've just started).

The intended application is a lot of very small blits, so I'd like to get
rid of per-blit overhead where possible.  I might just OwnBlitter(),
WaitBlitter(), SetIntVector(), and do it myself.  (Followed by, of
course, SetIntVector() and DisownBlitter().)  Stretching the rules, but
I think it's safe for the forseeable future.


Also, how much system overhead is there on Amy?  I have a couple of routines
I'm timing, one of which should take (by the 68000 manual) 105932 cycles per
call (there are not data dependencies), and I call it 50 times, so it should
take only slightly more than 44.4 vblank intervals.  I observed 51, 52, and
52, 15% over.

Another is 10% over its time, with 51 calls and an average of 190174 (slight
data dependency) cycles each.  It should take 81.3 vblanks, and I get 90.

The environment is an NTSC Amiga 1000, 4 MB fast memory, 2 floppies, a
floppy in each, no mouse or keyboard activity, vanilla WB 1.3 with Manx
tools in rad:, no daemons, pipe:, ram:, rad: and newcon: mounted.

Where is the time going?  Do vblank interrupts (gameport.device,
timer.device) and a bit of intuiticks activity take that long?


Many thanks to those more knowledgeable than I who can help.
-- 
	-Colin