Memory/bus access pattern on 68000

[chb]

Hi,

can the 68000 use two consecutive bus cycles (even and odd) in case it was blocked from access the cycle before? Background: According to the HRM, when doing an BD-blit, the pattern is

B0 -  -  B1 D0 -  B2 D1 -  D2

thus giving 4 idle cycles for 6 accesses. How many of these idle cycles can the cpu make use of? Only three, or all four? Assuming cpu runs at a stable every-second-cycle pattern without the blitter.

BTW, another (related) question: In the errata to the HRM, the cycle diagram for the above is given as

- B0 -  -  B1 D0 -  B2 D1 -  D2

giving an additional idle cycle at the beginning. Is this the correct one? So five idle cycles per six access cycles instead of four?

[paraj]

Originally Posted by chb

Hi,

can the 68000 use two consecutive bus cycles (even and odd) in case it was blocked from access the cycle before? Background: According to the HRM, when doing an BD-blit, the pattern is

B0 -  -  B1 D0 -  B2 D1 -  D2

thus giving 4 idle cycles for 6 accesses. How many of these idle cycles can the cpu make use of? Only three, or all four? Assuming cpu runs at a stable every-second-cycle pattern without the blitter.

BTW, another (related) question: In the errata to the HRM, the cycle diagram for the above is given as

- B0 -  -  B1 D0 -  B2 D1 -  D2

giving an additional idle cycle at the beginning. Is this the correct one? So five idle cycles per six access cycles instead of four?

As you know I'm a newbie, so take this with a grain of salt:

I interpret the cycle diagram as saying that once the blitter has started its pipeline (and before it enters the final cycles) the pattern will be B(N+1) DN -. I think the errata is just clarifying that a BD-blit will start one cycle later than e.g. an AD-blit.

My reading of the attached DMA visualization from WinUAE (I've grown quite fond of them ) seem to support this.

I don't know for sure, but I don't think the 68k can ever use both the even and odd slots, but I could certainly be wrong.

The following code was running (+some mouse checking etc.) when the screenshot was taken (only blitter DMA was enabled):

        move.l  #custom, a6
	move.l	#-1, bltafwm(a6)
	moveq	#0, d0
	move.w	d0, bltbmod(a6)
	move.w	d0, bltdmod(a6)
	move.w	#SRCB!DEST!$00, bltcon0(a6)
	move.w	d0, bltcon1(a6)
        move.l	#buf, d0
        move.l	d0, bltbpt(a6)
        move.l	d0, bltdpt(a6)
        move.w	#200*64, bltsize(a6)
	rept 1024*8
	moveq	#0, d0
	endr
        waitblit

[chb]

Thanks a lot! Yes, it makes totally sense that the two consecutive idle cycles appear only at the beginning - I should have read the paragraph more carefully, actually it's titled "pipeline register" for a reason . Still interesting what happens when the blitter has two idle cycles, some modes with fill enabled should have this behavior, e.g. D only with fill. I'll check in UAE.

[Kalms]

I am not 100% certain here, but I believe that the limiting factor is the 68000 microcode itself. It is written in such a way that the 68000 will not attempt memory accesses more often than every 4th cycle. Because of this, the CPU will not be able to utilize two free bus cycles that are directly after each other. (If it could, then CPU code would run significantly quicker during the no-display-DMA period compared to the 1-4bpl DMA period.)

[paraj]

Originally Posted by chb

Thanks a lot! Yes, it makes totally sense that the two consecutive idle cycles appear only at the beginning - I should have read the paragraph more carefully, actually it's titled "pipeline register" for a reason . Still interesting what happens when the blitter has two idle cycles, some modes with fill enabled should have this behavior, e.g. D only with fill. I'll check in UAE.

For reference I've attached a condensed version of what I used for timing. (Try adding DMAF_BLITHOG for a nicer DMA pattern ).

(I press shift+f12 and then type "v -3" enter, "g" and close the debugging window - Note: this seems to crash WinUAE 3.3.0 in some configurations... Haven't investigated further).

[chb]

I was thinking that maybe there's some internal flexible pipelining going on, e.g. a storage operation can be deffered to a later time, so that a cycle like CxCxCxCx (bus cycles, C cpu, x something with higher priority) can become CxCxxCCx. So not faster, only more flexible, and interleaving better with some blitter operations.
The original motivation was to find a blitter operation that, when running without other dma, does not slow down the cpu (using only every second cycle), apart from Zero-check or D only operations. I wasn't shure what happens if the cycle diagram gets e.g. B1 D0 - - B2 D1 - - B3 D2 - -, if both idle cycles are usable or only one, but I can check with UAE dma debugger, that's actually a good idea.

EDIT: paraj, thanks a lot for the code!

[Kalms]

As far as I know there is no such pipelining within the 68000. Will be interested to hear if you find out otherwise

[paraj]

Originally Posted by Kalms

As far as I know there is no such pipelining within the 68000. Will be interested to hear if you find out otherwise

Looking at the cycle diagrams in M68000 8-/16-/32-BIT MICROPROCESSORS USER'S MANUAL it doesn't seem like it's possible have to two memory accesses in less than 4 clock cycles. The only deviation from the standard access pattern is the infamous TAS-instruction and even then the CPU isn't requesting memory more often. The 4cc/mem assumption is probably deeply embedded in the custom chip design (I'm not really a HW-person, but I figure the design of the chips can be made a lot easier given that simplifying assumption). The simplest CPU design would also just be to halt the CPU (stay in the same state) until the bus is free. But that's just speculation on my part (and my reading of the diagrams could be wrong).

I found this article about memory controller design for the 68k interesting: http://www.bigmessowires.com/2011/08...roller-design/

[paraj]

Originally Posted by chb

I was thinking that maybe there's some internal flexible pipelining going on, e.g. a storage operation can be deffered to a later time, so that a cycle like CxCxCxCx (bus cycles, C cpu, x something with higher priority) can become CxCxxCCx. So not faster, only more flexible, and interleaving better with some blitter operations.
The original motivation was to find a blitter operation that, when running without other dma, does not slow down the cpu (using only every second cycle), apart from Zero-check or D only operations. I wasn't shure what happens if the cycle diagram gets e.g. B1 D0 - - B2 D1 - - B3 D2 - -, if both idle cycles are usable or only one, but I can check with UAE dma debugger, that's actually a good idea.

EDIT: paraj, thanks a lot for the code!

NP. If you trust WinUAE you can also cheat and look at the source:
https://github.com/tonioni/WinUAE/bl...itter.cpp#L100

which matches the observed BD- pattern.

[Toni Wilen]

(Didn't remember to answer earlier)

68000 memory access is always 4 cycles (EDIT: or more if DMA steals cycles from CPU) but it can start in any 2 cycle boundary. There is no pipelining, previous or next instruction has no effect on current instruction execution timing.

BD-blit

-B- -BD -BD

If A channel is disabled, it becomes idle cycle. Blitter also has 2 extra idle cycles at the start of each blit.

[chb]

@all Thanks a lot for your help and the valuable information! Seems like my original idea does not work. Quite a pity that there's no cpu-over-blitter-priority mode, would come in handy in a couple of scenarios...

[Photon]

Originally Posted by chb

Hi,

can the 68000 use two consecutive bus cycles (even and odd) in case it was blocked from access the cycle before? Background: According to the HRM, when doing an BD-blit, the pattern is

B0 -  -  B1 D0 -  B2 D1 -  D2

thus giving 4 idle cycles for 6 accesses. How many of these idle cycles can the cpu make use of? Only three, or all four? Assuming cpu runs at a stable every-second-cycle pattern without the blitter.

BTW, another (related) question: In the errata to the HRM, the cycle diagram for the above is given as

- B0 -  -  B1 D0 -  B2 D1 -  D2

giving an additional idle cycle at the beginning. Is this the correct one? So five idle cycles per six access cycles instead of four?

(Not a direct answer, just a general note: HRM shows the init, loop, and exit slot allocation for a minimum blit size. Only go by the loop part - but I guess you figured that out.

If BLTPRI is on, only a very few blit types and weird minterms give cycles to the CPU, even when there are zero bitplanes etc stealing higher priority DMA cycles. B->D minterm is one of the weird minterms

In other words, since B has the same capabilities as A (but C does not), if you used B for data instead, the blit would finish sooner.