Thread View: comp.sys.amiga.tech
3 messages
3 total messages
Started by Colin Plumb
Mon, 17 Dec 1990 07:52
Questions about QBlit(), etc.
Author: Colin Plumb
Date: Mon, 17 Dec 1990 07:52
Date: Mon, 17 Dec 1990 07:52
61 lines
3275 bytes
3275 bytes
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
Re: Questions about QBlit(), etc.
Author: Randell Jesup
Date: Wed, 19 Dec 1990 08:24
Date: Wed, 19 Dec 1990 08:24
28 lines
1815 bytes
1815 bytes
In article <1990Dec17.075228.15068@watdragon.waterloo.edu> ccplumb@spurge.uwaterloo.ca (Colin Plumb) writes:
>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?
Don't forget trackdisk checking disk insertion/removal every .5sec
if there's a disk in the drive, 2.5s without a disk.
10% is quite possible.
--
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.commodore.com BIX: rjesup
The compiler runs
Like a swift-flowing river
I wait in silence. (From "The Zen of Programming") ;-)
Re: Questions about QBlit(), etc.
Author: Loren Rittle
Date: Thu, 20 Dec 1990 06:30
Date: Thu, 20 Dec 1990 06:30
29 lines
2084 bytes
2084 bytes
Randell Jesup writes recently:
>Don't forget trackdisk checking disk insertion/removal every .5sec
>if there's a disk in the drive, 2.5s without a disk.
Of course, (for those of us with old drives that noclick can't help :-()
we also get to hear that click every 2.5s or more often with two
drives. :-)
Is there a system friendly way to turn off the floppy drives all together?
I never use them during a productivity session at my Amiga. I use my
hard-drive and tape-drive most of the time. Floppies are only used
to load new software onto my machine, or play those games that don't
allow themselves to be installed :-(!
OK, barring a friendly way, what's a mean way :-). I am strongly
opposed to others frocing my system do to evil things, but if I
preform the evil action, it's OK! I just need a reliable way to
shut down the trackdisk.device right? Nuke (came with GOMF, :-)
caused a nice firework display to appear 1 out of 5 (about)
times thus I don't think it is reliable.
Thanks for any help,
Loren J. Rittle
PS (I know it is possible to boot the machine without having the
motherboard connection to the floppies, no trackdisk.device is
started up and the machine autoboots fine! :-) This seems a bit
extreme though, :-) thanks
--
``In short, this is the absolute coolest computer device ever invented!''
-Tom Denbo speaking about The VideoToaster by NewTek
``Think about NewTek's VideoToaster! Now think about the Amiga!''
Loren J. Rittle lrg7030@uxa.cso.uiuc.edu
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads