MEGA ST BLITTER PATCH - Discussion thread

[Badwolf]

So, if someone were being *really* anally retentive about wanting all their blitters to return $3f in your test case, would delaying the blitter's BR line by one 8MHz clock cycle be sufficient?

I can say just a few ns on the 8Mhz clock on the CPU "does the trick". So I would imagine delaying BR would have the same effect. But it also begs the question if it is already 003F and you delay further with it further screw up the results @ijor ?

I was thinking it'd push the S2 assertions into S4 and ensure nothing asserts in S0. I don't think there should be a difference between S2 and S4 assertion as it's not sampled until S7, if I've read Ijor's post correctly.

There probably will not be any future H5 series boards.

Ah, fairy nuff.

BW

[ijor]

So, if someone were being *really* anally retentive about wanting all their blitters to return $3f in your test case, would delaying the blitter's BR line by one 8MHz clock cycle be sufficient?

Yes, pushing BR assertion to S2/S4 would work, in the sense that all Blitters would get the same result, both when running this test and with typical Blitter code. Guess some may argue that it is not really good because "most" Blitters on a standard ST/STE would return $40 when running the test. Also note that you would still get different behavior depending on the Blitter part, if the bus is idle for more than two clock cycles.

Btw, I just realized that S0/S2 technically might be incorrect terminology here because the bus is, or might be, idle at what I called S0. A more accurate accurate (but too long) wording might be perhaps:

A fast Blitter (CPU combination) asserts BR at the next raising edge of the clock after the bus cycle that sets BUSY, at the phase that would be S0 if there are no idle states and the next bus cycle starts immediately. While a slow Blitter (CPU combination) asserts BR one cycle later, at the phase that would be S2 if the next bus cycle starts immediately without any idle states.