CPU cycles left, when Blitter is busy

[Rock'n Roll]

I know the blitter cycle diagram but I don't get a relation to the DMA-debugger output.
If I look in the dma-debugger output I can't see a special blitter idle cycle information. I only see BLT-A, BLT-B, BLT-C, BLT-D.

OK, if I use the normal D-copy. I see the a 'B' sign. It's a notice to a idle cycle. This cycle is used by the CPU then.
Or I can see a 'S' sign in normal more channel blitter operation (BLITPRI=0). But no idle cycle would be moved.
And it is clear the the blitter works further after a CPU-cycle (or other higher dma-cycle) with his next step.

And I also know, any blitter cycle needs free cycle, even if it is idle cycle and CPU can use any idle blitter cycle.

B = blitter needed this cycle but it is also available for CPU if CPU needs it.
(=blitter idle cycle which means blitter did some internal operation but it
didn't need bus hardware = CPU can still access chip bus)

S = CPU stole this cycle from blitter

For me it's also at least 4 cycles not 3, and then the next. (5.) cycle the CPU gets the bus access if no other higher dma want use it.
And if BLIPRI=1, CPU can't steel any cycle. Or not? I only try to understand the rules.

[Rock'n Roll]

ok, the blitter idle-cycle point is clear now:
https://eab.abime.net/showpost.php?p...29&postcount=2

a good example for the blitter idle cycle is a B->D or C->D copy
blitter cycle diagram: BD-BD-BD- or CD-CD-CD- and each '-' is a idle cycle, CPU can use the idle-cycle and
it is marked with 'B' in DMA-debugger and also if BLITPRI=1 this cycle can be used from CPU.

but this point isn't clear for me:

HRM says: If DMAF BLITHOG is a 0 (BLITPRI=0), the DMA manager will monitor the 68000 cycle requests. If the
68000 is unsatisfied for three consecutive memory cycles, the blitter will release the bus for one cycle.

And this graphic https://www.powerprograms.nl/amiga/c...b27f12-601.png
shows this waiting for three memory cycles.

But DMA-Debugger shows every 5. cycle. What is the explanation for this? And that confuse me.

[10  16]  [11  17]  [12  18]  [13  19]  [14  20]  [15  21]  [16  22]  [17  23]
 BLT-C 70  BLT-D 00  BLT-A 74  BLT-B 72    CPU-RW  BLT-C 70  BLT-D 00  BLT-A 74
     FFFF      FF80      0000      3FFF  S   0280      C000      FFFF      0000
 0001F87A  0002014A  0001FA74  0001F978  00C2C698  0001F87C  0002016E  0001FA76
 B68C3200  B68C3400  B68C3600  B68C3800  B68C3A00  B68C3C00  B68C3E00  B68C4000

 [18  24]  [19  25]  [1A  26]  [1B  27]  [1C  28]  [1D  29]  [1E  30]  [1F  31]
 BLT-B 72    CPU-RW  BLT-C 70  BLT-D 00  BLT-A 74  BLT-B 72    CPU-RW  BLT-C 70
     FF80  S   8000      0000      FFFF      0000      0000  S   611F      FFFF
 0001F97A  00DFF004  0001F87E  00020170  0001FA78  0001F97C  00DFF006  0001F880
 B68C4200  B68C4400  B68C4600  B68C4800  B68C4A00  B68C4C00  B68C4E00  B68C5000

[paraj]

Originally Posted by Rock'n Roll

HRM says: If DMAF BLITHOG is a 0 (BLITPRI=0), the DMA manager will monitor the 68000 cycle requests. If the
68000 is unsatisfied for three consecutive memory cycles, the blitter will release the bus for one cycle.

And this graphic https://www.powerprograms.nl/amiga/c...b27f12-601.png
shows this waiting for three memory cycles.

But DMA-Debugger shows every 5. cycle. What is the explanation for this? And that confuse me.

Image is not accessible to me, but I think I tried to explain this earlier in the thread. 7MHz 68000 running as fast as possible (e.g. only executing NOP instructions) can only access memory every 4th CPU cycles (== every other CCK).


With only CPU and blitter running (and BLTPRI=0) you will see CBBBBC. Because first you have CPU internal cylce (2 CPU, 1 CCK), then it starts waiting and the 3 (CCK) cycle waiting limit Toni mentions kicks in.


If instead of NOPs the CPU is doing e.g. LSL.W #8,D0 you will see a pattern of CBBBB-(CPU starts wanting to access memory)-BBBC (may have off by one error here, but hopefully you get the idea, and try with MUL/DIV instructions to see it for maximum effect).