Using the disk DMA to clear memory?

[DanScott]

Is this possible? Saw this mentioned in a FB thread... anyone done this?

[ross]

Originally Posted by DanScott

Is this possible? Saw this mentioned in a FB thread... anyone done this?

Even if possible, isn't it very slow? (only 3 DMA slot /line..).
Or is it just a proof of concept?

[DanScott]

Someone said they had used it, and it had help save some cycles...

[ross]

Let's do two calculations:
you can clear 1878byte/frame, so for a simple 320x256 single plane you need 10240/1878=5,45 50Hz frames to do it..
With the blitter you need only few video lines for the same bitplane (using also the same DMA slots of the unused DISK DMA).
I dont see any advantage.

The only (negligible) use could be to clear small areas of memory in a deferred way from the blitter and the processor.
Nothing striking.

EDIT: anyway for a DISK DMA start you need a 'signal' from Paula and the MFM bit stuffing is at max 2ns/bit, so this 'virtual' figure is smaller..
all this for me has no logical use (even if it were possible)

[FSizzle]

When clearing, using one channel only, the blitter cannot write during every available DMA slot. In the same way that you can clear memory on the 68000 more quickly by using the blitter and CPU simultaneously, couldn't you use the disk DMA and blitter simultaneously, accelerating the clear with the disk DMA slightly?

I'm not sure how you'd make the disk DMA write the desired data though.

[Thomas Richter]

Originally Posted by DanScott

Is this possible? Saw this mentioned in a FB thread... anyone done this?

Yes, as long as this is chip memory. Yes. And the function for that is in the graphics.library, named "BltClear()".

[FSizzle]

And the function for that is in the graphics.library, named "BltClear()".

That function uses the blitter. OP is asking about using disk DMA.

[ross]

Originally Posted by FSizzle

When clearing, using one channel only, the blitter cannot write during every available DMA slot. In the same way that you can clear memory on the 68000 more quickly by using the blitter and CPU simultaneously, couldn't you use the disk DMA and blitter simultaneously, accelerating the clear with the disk DMA slightly?

I'm not sure how you'd make the disk DMA write the desired data though.

When i want a quick routine to clear the chip memory i always use the blitter and the CPU together, so that all access cycles to chip ram are used (0 minterm and movem).
So it makes no sense to use the DISK DMA, in any case its allocated DMA slot cycles would be used by the blitter.

[Thomas Richter]

Originally Posted by FSizzle

That function uses the blitter. OP is asking about using disk DMA.

Oh, I'm sorry. Concerning disk-DMA: How could one ensure that the input data at Paula is 0, which is necessary for cleaning?

[meynaf]

Originally Posted by ross

So it makes no sense to use the DISK DMA, in any case its allocated DMA slot cycles would be used by the blitter.

Using the blitter may slow the cpu down. But as disk dma slots are allocated regardless if they are used or not, there may be some interest in having them do something basically for free.

Originally Posted by Thomas Richter

Concerning disk-DMA: How could one ensure that the input data at Paula is 0, which is necessary for cleaning?

By writing to DSKDAT maybe ?

[ross]

Originally Posted by meynaf

Using the blitter may slow the cpu down. But as disk dma slots are allocated regardless if they are used or not, there may be some interest in having them do something basically for free.

This is not completely right.
Yes that blitter can slow down the CPU, but it can use every free cycle (as the CPU), that in this specific case could be also DISK DMA cycles.

So these cycles "allocated regardless if they are used or not" are usable/used by the blitter/CPU during the clear operation

As I've written, the only (negligible) use could be to clear small areas of memory in a deferred way from the blitter and the processor (but not 'instead').

[Toni Wilen]

If audio or disk or any DMA slot is not used by higher priority Agnus DMA channel, it is always usable by blitter or CPU (if blitter or CPU needs it).

Allocation is dynamic, unused DMA slots are never unavailable for blitter or CPU.

[ross]

Originally Posted by Toni Wilen

If audio or disk or any DMA slot is not used by higher priority Agnus DMA channel, it is always usable by blitter or CPU (if blitter or CPU needs it).

Allocation is dynamic, unused DMA slots are never unavailable for blitter or CPU.

Toni is totally right here

[roondar]

Originally Posted by ross

Toni, in this case only by blitter because CPU cannot access chip memory during slots allocated for AUDIO or DISK DMA.
Of course different for other Agnus DMA channels.

I thought if disk DMA or audio DMA is in use then neither Blitter nor CPU can access any cycles the disk or audio DMA requires*?

But if there are free disk/audio "slots" then surely both the CPU and Blitter could access them?
Edit: assuming the CPU manages to get aligned to the correct slots to do so, obviously. It'll still only access memory every other cycle at best.

*) that is, not cycles during which disk/audio DMA are running but idle, but cycles where disk or audio DMA actually needs to access memory for that particular slot.

[ross]

Originally Posted by roondar

I thought if disk DMA or audio DMA is in use then neither Blitter nor CPU can access any cycles the disk or audio DMA requires*?

Partially yes (see next point), only video DMA can 'steal' cycles allocated for 'Paula''s requests to Agnus (and is not a good thing, because can steal also memory refresh slots).
EDIT: anyway this is not simple, i think only on AGA you can 'overrun' bitplane DMA up to DISK/AUDIO slots but sure OCS/ECS for refresh slots.

But if there are free disk/audio "slots" then surely both the CPU and Blitter could access them?
Edit: assuming the CPU manages to get aligned to the correct slots to do so, obviously. It'll still only access memory every other cycle at best.

EDIT2: yep, your edit is right

[roondar]

Originally Posted by ross

P
Your edit is the focal point.
CPU can access only every other cycle at best, not these for AUDIO or DISK DMA, that can be instead used by blitter.

Just to be complete here and as I understand it:

If the CPU gets "misaligned" somehow at the start of a scanline, it will use all the AUDIO/DISK DMA channels slots (and sprite, etc) that are available until it's forced back into alignment. It definitely won't make much of a practical difference and often such misalignment is very temporary, but it's certainly theoretically possible for the CPU to be so aligned for all of those cycles in a scanline.

If this understanding is wrong, well, I'd love to learn

-----
On the topic of clearing with disk DMA and it's usefulness: thinking about this a bit more, I can see a "kind of, maybe" use-case here. Now, this definitely won't improve performance, but might still be useful in some scenarios.

You could effectively use this as a sort of "fire-and-forget" memory clear that just does it's thing while rest of the code gets run for the frame. So for instance, you could call disk DMA to clear a small section of memory you need to use next frame, while the rest of the code goes on doing other stuff with the Blitter or CPU. Not sure how useful this is, but it's still perhaps interesting.

[ross]

Originally Posted by roondar

Just to be complete here and as I understand it:

If the CPU gets "misaligned" somehow at the start of a scanline, it will use all the AUDIO/DISK DMA channels slots (and sprite, etc) that are available until it's forced back into alignment. It definitely won't make much of a practical difference and often such misalignment is very temporary, but it's certainly theoretically possible for the CPU to be so aligned for all of those cycles in a scanline.

If this understanding is wrong, well, I'd love to learn

argh, you are right! CPU can misalign and use also these cycles! (the resulting effect does not change, but this specificity exists)
EDIT:
I'll edit my previous message adding CPU more than blitter access possibility on these DMA slots (Toni is always right )

On the topic of clearing with disk DMA and it's usefulness: thinking about this a bit more, I can see a "kind of, maybe" use-case here. Now, this definitely won't improve performance, but might still be useful in some scenarios.

You could effectively use this as a sort of "fire-and-forget" memory clear that just does it's thing while rest of the code gets run for the frame. So for instance, you could call disk DMA to clear a small section of memory you need to use next frame, while the rest of the code goes on doing other stuff with the Blitter or CPU. Not sure how useful this is, but it's still perhaps interesting.

And this is my mentioned 'deferred' use case

[Toni Wilen]

Originally Posted by ross

argh, you are right! CPU can misalign and use also these cycles! (the resulting effect does not change, but this specificity exists)
EDIT:
I'll edit my previous message adding CPU more than blitter access possibility on these DMA slots (Toni is always right )

Not being able to use and not requesting the free cycle are in my opinion totally different things

There are also instructions that have non 4 divisible cycle counts and long instructions like MUL and DIV.

[ross]

Originally Posted by Toni Wilen

Not being able to use and not requesting the free cycle are in my opinion totally different things

There are also instructions that have non 4 divisible cycle counts and long instructions like MUL and DIV.

I've written a little test prog with unrolled movem series interleaved by a 6 cycles lsr d0,d0 (d0=0) and in VisualDMA debugger the effect is pretty visible.

[FSizzle]

This post asks:

Can you clear memory using disk DMA?

Which is a fascinating question to me because it's not one I heard before.

Assuming it's possible, the implicit follow up question is:

Is there a situation that is useful or gives some benefit?

I can think of a situation in which it could be a performance enhancement and not just a curiosity. I tried to allude to this before, but didn't explain it very well (or really at all) so let me try again:

Let's say you have the following situation:
- CPU is not using the chip RAM bus much, or at all (doing expensive internal operations or running out of fastram)
- you want to clear a buffer

If you use the Blitter, in D channel mode as normal, you cannot utilize every chipram access cycle due to how the blitter works, so your bus access looks like:

-B-B-B-B-B-B-B-B-B-B-B-B...

- = Idle    B = Blitter

If you were to use the disk DMA, it looks like this:

-D-D-D-------------...

- = Idle    D = Disk

Now if you combine the two, I think you will get this:

-DBDBDB-B-B-B-B-B-B-B-B-...

- = Idle    B = Blitter    D = Disk

i.e. on the first conflicting access between the Disk and Blitter, the Disk will have priority, resulting in delaying the blitter. From that point on there should be no contention.

If I'm right about this behavior, you now have ~1.8 KiB of extra clearing bandwidth per frame.

Naturally you could replace the blitter clear operation with some other operation that also cannot saturate the bus as well (like an A->D copy of for example) and similarly be able to utilize some extra chip ram access slots.

I could be wrong about the timing, or the effect the contention would have on delaying the blitter. It could be proven either way with a small piece of test code, but I bet Toni also just knows