MEGA ST BLITTER PATCH - Discussion thread

[atari030]

Without drifting too far down river. How does the MegaSTE differ blitter wise? I've noticed (with some disappointment) that demo's like Sea of Colour will not work on MegaSTE's. DHS's blurb mention something about timing.

Maybe the MegaSTE has the blitter already combined in the MCU ? I know the STe can have external blitter with earlier MCU that have not that.

There are two variants, one is built into the MCU, the other isn't. The latter uses a standard blitter.

[ijor]

@ijor These are what I found so far. All show 0040.

Strange that you don't get $003F with any of the "ST" branded Blitters. On the AF thread, every ST Blitter except one gave a $3F result. Just for completeness, on which machine you performed the tests?

Without drifting too far down river. How does the MegaSTE differ blitter wise? I've noticed (with some disappointment) that demo's like Sea of Colour will not work on MegaSTE's. DHS's blurb mention something about timing.

This has nothing to do with a different Blitter. It is the extra logic on the MSTE board that delays some of the bus acquisition (DMA) signals.

[exxos]

Strange that you don't get $003F with any of the "ST" branded Blitters. On the AF thread, every ST Blitter except one gave a $3F result. Just for completeness, on which machine you performed the tests?

On a H5 rev C1.

[ijor]

Strange that you don't get $003F with any of the "ST" branded Blitters. On the AF thread, every ST Blitter except one gave a $3F result. Just for completeness, on which machine you performed the tests?

On a H5 rev C1.

If you can, it might be interesting to test on an "original" (not a REMAKE) computer, MST, STE, or ST with Blitter.

[exxos]

If you can, it might be interesting to test on an "original" (not a REMAKE) computer, MST, STE, or ST with Blitter.

I've tried a stock STE. One of the ST blitters shows 003F (the one with the red sticker, ive not tried them all again). I swapped to a HC CPU and went to 0040.

[exxos]

I did a little bit more poking around. Ironically with a V1 STE booster the value went back to 0038 despite having a HC CPU.

Long story short, it seems to be relating to the 8Mhz clock. As soon as there is a buffer in there it changes from 0040 to 0038. Probably is only something like 2ns delay.

I guess really someone would need to get a high-speed logic analyser on all the CPU control pins and see exactly what is changing. As it stands I would have to say that I have not seen any real differences between blitter brands or date codes. It just seems to be "more of the same" screwy faults between various machines as usual. Likely just tollerences on chips.

EDIT:

Maybe the NMOS CPU doesn't respond to BR fast enough ?, but the HC CPU can. As when the 8Mhz is delayed a few ns, BR will be slowed to the CPU enough to skip a few clocks

EDIT2:

Assuming blitter is counting /AS pulses.. It would probably need some logic to keep /AS high on the blitter while /BR is low and /BGACK is high. So the cpu may, or may not do a bus cycle, but blitter does not see /AS low and doesn't count it. Then when it sees /BGACK , /AS is allowed to the blitter again. Not simple to fix really.

[Badwolf]

Assuming blitter is counting /AS pulses..

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

BW

[exxos]

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

From what I understand , which could be wrong, the blitter does this counting internally. It's supposed to count 64 blitter cycles, but it's counting any bus cycle and ends up actually counting 63. Hence the 0040 & 003F results. The CPU finishes its current cycle ( or happens to start a new one ) which the blitter counts, when it shouldn't. Oddly it doesn't happen with the HC CPU. Unless the 8mhz clock is buffered and it screws the count up anyway.

My initial thought is what I said in my previous post. Likely BR and AS would have to be cut from the blitter and some logic in there to hold off ( I assume ) /AS from the blitter until the CPU set BGACK low. Basically stops the blitter from seeing any bus cycles until the CPU sets BGACK low. The blitter is then in control and can count bus cycles correctly.

EDIT: Actually, isn't BR a series arrangement ? Was thinking any bus master can request the bus hence cutting BR from the blitter probably no need / no point. Just cutting /AS from the blitter and add some logic to monitor BR and BGACK. But probably jumping ahead with this idea currently.

I guess the logic would be something like this:

BLITTER_AS = SYS_AS # (!BR & BGACK);

Probably need a buffer to allow blitter to set SYS_AS low as well.

Or maybe a bidirectional bus transceiver with a enable pin linked to BGACK might be enough.

[ijor]

I've tried a stock STE. One of the ST blitters shows 003F (the one with the red sticker, ive not tried them all again). I swapped to a HC CPU and went to 0040.

Interesting. This confirms it is an analog issue.

As it stands I would have to say that I have not seen any real differences between blitter brands or date codes. It just seems to be "more of the same" screwy faults between various machines as usual. Likely just tollerences on chips.

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

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).

Maybe the NMOS CPU doesn't respond to BR fast enough ?, but the HC CPU can.

Not exactly, but sort of. 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.

I guess really someone would need to get a high-speed logic analyser on all the CPU control pins and see exactly what is changing.

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.

[ijor]

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

From what I understand , which could be wrong, the blitter does this counting internally. Its supposed to count 64 blitter cycles, but its counting any bus cycle and ends up actually counting 63. Hence the 0040 & 003F results. The CPU finishes its current cycle ( or happens to start a new one ) which the blitter counts, when it shouldn't.

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. It (wrongly) assumes that all AS pulses at this point are Blitter own pulses. But typically, the CPU would take one more bus cycles for himself before granting the bus.

Now, this is not by itself the issue here. This buglet (if you want to call it like that) is well known and it is then harmless. I don't think there is any need to "fix" this. The issue is that in some cases different Blitter parts might have different behavior. What my test does is to trigger Blitter with a special CPU sequence so that the CPU would (normally) grant the bus immediately. Then it reads how many words were actually blitted. That's why you get $40 (64) as a normal result in most cases. Except on some Blitter/CPU combination that miss one cycle and perform $3F bus cycles.