MEGA ST BLITTER PATCH - Discussion thread

[exxos]

Did you get $003F with the I60611 or the National branded Blitter, even on a plain STE (or MST) with an NMOS CPU?

I60611 MOT & HC CPU 0040
MM9092V MOT & HC CPU 0040

The ST chips are a bit of a mixed bag with a MOT CPU.

8833 USA - 003F.
8945 KOREA - 003F.
8929 KOREA - 0040.

I can only assume it is certain batches of ST CPU which do not "work correctly" with a MOT (NMOS) CPU. All work fine with a HC CPU in a STE or H5.

At this point I believe it is a combination of both the Blitter part/brand and the CPU (plus other motherboard changes that might slightly alter the timing).

Usual chaos then basically.

From what I can infer is that some Blitter chips are a bit slower in processing some CPU signals and might react one cycle later. But if the CPU happens to be faster, faster in the sense that output control signals are updated slightly earlier (technically, a smaller Tco), then that same "slower" Blitter might still process them in time.

Makes sense.

I believe a 4 channel scope might be good enough. If you have one are interested, scope 8MHZ,AS,BR,BG. We might even detect the issue with 2 channels, AS & BR.

Edit: If somebody want to try with a high frequency logic analyzer, then adding UDS and or RW might be helpful.

I only have a two channel scope and only one working probe currently. So not something I can do unfortunately.

[Badwolf]

Yes, Blitter counts 64 bus cycles (counting 512 clock cycles would be incorrect and more expensive) to relinquish the bus in non-hog mode. But Blitter has a buglet, it counts every active edge on the AS signal once it requested the bus.

Ok, yes, sorry. I had misunderstood how it did its business, in that case.

BW

[Cyprian]

Assuming blitter is counting /AS pulses..

Would it not simply be counting clock cycles down from 512, or have I misunderstood the phenomenon?

BW

the BLiTTER counts the bus slots used by the CPU. E.g. MULS instruction which takes a lot of cycles, but a few bus cycles, can massively delays the BLiTTER activity (its each pass will be delayed)

[exxos]

Managed to find a scope probe!

So this is AS and BR.

MOT_3F.JPG (148.38 KiB) Viewed 2308 times

HC_40.JPG (161.89 KiB) Viewed 2308 times

So at first glance I would have to say there does not appear to be any difference. But this might not even be blitter activities so I will run GB6 and re-test.

[exxos]

So this kinda makes my brain hurt. I mean yeah, CPU gets BR sooner on the HC, but why ?!

The MOT has just started a bus cycle when it gets BR. The HC gets BR while not doing a bus cycle. But don't get why this changes with the CPU as BR comes from the blitter surely ?!

All going by the /AS pulses they look identical in both cases. So is there actually any difference or not ?!

I guess really we need to see BG as well I guess as BR is known I can swap to BG instead.

MOT.JPG (278.97 KiB) Viewed 2305 times

HC.JPG (292.32 KiB) Viewed 2305 times

[exxos]

So this is /AS and /BG.

So the HC does grant the bus sooner (at a guess about 50ns by the looks of it) . But its still in the same low period of /AS. So does it really matter or not ?

MOT.JPG (284.27 KiB) Viewed 2297 times

HC.JPG (278.74 KiB) Viewed 2297 times

[ijor]

I60611 MOT & HC CPU 0040
MM9092V MOT & HC CPU 0040

The ST chips are a bit of a mixed bag with a MOT CPU.

8833 USA - 003F.
8945 KOREA - 003F.
8929 KOREA - 0040.

Great. Very useful tests! Thank you

I can only assume it is certain batches of ST CPU which do not "work correctly" with a MOT (NMOS) CPU. All work fine with a HC CPU in a STE or H5.

Yeah, this seems to be more or less the conclusion. Although I wouldn't make an absolute distinction between NMOS and CMOS CPUs. I believe there are reports with the "slow" ($3F) result even on CMOS. CMOS CPUs tend to have better analog characteristics. But surely some are faster than others.

So this kinda makes my brain hurt. I mean yeah, CPU gets BR sooner on the HC, but why ?!

The MOT has just started a bus cycle when it gets BR. The HC gets BR while not doing a bus cycle. But don't get why this changes with the CPU as BR comes from the blitter surely ?!

The "slow" Blitter asserts BR one cycle later on a "non-fast" CPU because it enters busy mode one cycle later. This in turn, I assume, it's because the (non-fast) CPU ends the write cycle that starts the Blitter slightly later. I'll elaborate more later.

[ijor]

Elaborating a little more about the "slow" Blitter issue.

Blitter requests the bus as soon as possible after BUSY was internally set. BR is asserted synchronously at the next raising edge of the clock. The CPU sets BUSY by writing, precisely, to the BUSY bit on the control register. But BUSY is not internally acknowledged until the write bus cycle is completed. This happens when the CPU desserts UDS & LDS at the falling edge of S7. There is only half cycle to the next raising edge of the clock. If all goes well and fast enough, Blitter will assert BR at S0.

But obviously, nothing is instantaneous. There is a delay from the falling edge of the clock at S7 until the actual trailing edge of UDS/LDS. And there all sort of internal delays in Blitter since that DS trailing edge, to the flip flop that drives BR. If the Blitter/CPU combination is not fast enough, this delay would take more than half cycle and would be too late for the next raising edge of the clock. Then Blitter would assert BR one cycle later, at S2 instead of S0.

For comparison the Motorola specification for the fastest 68HC000 is just 25ns from the clock edge to the DS edge, but more than 65ns for the slowest CPU. This is the worst case, not the typical or average delay. But illustrate the possible huge differences between different CPU variants.

Now, why this changes the number of words blitted. Normally, with the typical Blitter CPU code, asserting BR at S0 or S2 won't make any difference at all. This is because the CPU would take the bus by itself already at S0. And then it will grant the bus only at the next bus cycle, regardless if BR was asserted at S0 or S2. But in this test I'm using a special CPU sequence that leaves the bus idle for a couple of cycles. If BR is asserted at S0, the bus is granted immediately. If BR is asserted at S2, instead, it is too late and the CPU performs an extra bus cycle for itself.

This combines with the "buglet" Blitter described on previous messages. Blitter counts 64 bus cycles, any bus cycle, after requesting the bus. If BR was asserted at S0, Blitter will get the bus immediately, and all the next 64 bus cycles would be its own. But if BR is delayed for S2, the first of the next 64 bus cycles would be for the CPU. So Blitter would perform 63 bus cycles only.

A couple of notes are relevant. In first place note again that this difference doesn't affect the typical Blitter code. This is why most, probably all, demos that require Blitter cycle accuracy still work fine even with a "slow" Blitter.

In second place these "slow" Blitter parts aren't necessarily generally slow. It could be. May be they were fabbed with a slower CMOS process, or with lower quality. But it is also possible that the logic was slightly changed and these "slow" Blitter have additional gates at the relevant logic that takes an extra delay. As Exxos showed at the start of this thread, some Blitter schematics do have additional buffers. As a matter of fact I believe that there a couple of buffers added in one version that might be relevant for this delay.

[Badwolf]

Elaborating a little more about the "slow" Blitter issue.

Very nice explanation, Ijor and worthy of being transcribed to the new Wiki, I feel.

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'm thinking something optional that could be integrated into the next H5 revision)

BW

[exxos]

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'm thinking something optional that could be integrated into the next H5 revision)

There probably will not be any future H5 series boards. It cost several thousand to put a batch into production and they just do not sell well enough to really consider it. But this is in part why I was considering a smaller legacy board to get the costs down etc and I was talking with @Icky a couple years back about designing a smaller case similar to the STM for it.. Incidentally a future board would be more FPGA based to replace the MMU,GLUE,BLITTER so that is a whole different can of worms to go into. But getting off topic here anyway.