Blitter on H5 Test

[ijor]

I will see if I can find the original emails where we was discussing it. I think he waited for the vbl and the next time a tick as the reference point but this is going back some years to don't exactly remember. I do remember during development it was tested both ways and did not seem to make any difference. I thought that code was left in place.
...
So this looks like some of the original notes @dml sent me. I know this is getting slightly off topic but anyway..
...
I cannot specifically find anything mentioning the VBL in relating to start time.. But might be the "sync-lock" which is mentioned. But so many emails over the years..

The notes you posted from dml messages confirms what I was saying. Except for the IKBD, interrupts are not disabled, they are kept enabled by design. And the mentioned sync lock is to synchronize with the timer C interrupt, not with the vertical blank.

The 99% issue can still be rounding-related.
...
14.605 100% -2921 ticks
14.610 100% - 2922 ticks
14.615 99% - 2923 ticks

You definitely seem to have a rounding problem. The difference between 2921 and 2923 ticks is less than 0.1%, not anywhere near 1%. But I'm not familiar with basic to comment on the rounding implementation.

Indeed if you have any suggestions for improvement for any of these loops then I can add that into GB7 and trial.

I didn't note it before. But I now think that the rounding problem seems to be more significant than the actual timing accuracy.

[ijor]

Picture 1 - Mega ST4, TOS v2.06, AdSpeed accelerator @16mhz:
Picture 02 - Same machine, AdSpeed accelerator@8mhz (turned off by CPX software):
And finally, the confusing one... (really not sure what's going on there)
Picture 03 - Same machine, clean boot, no AUTO folder programs, etc:
MegaST4-BlitterTest03.JPG

Hi Darklord,

This test will fail with any kind of accelerator. Seems that even when you disable the accelerator, the computer still doesn't work exactly like a "standard" one. I checked the accelerator documentation, and it mentions some special circuitry regarding Blitter, that might be the reason.

[Darklord]

Hi Darklord,

This test will fail with any kind of accelerator. Seems that even when you disable the accelerator, the computer still doesn't work exactly like a "standard" one. I checked the accelerator documentation, and it mentions some special circuitry regarding Blitter, that might be the reason.

Understood.

Although in my case, I did not make any alterations involving the blitter chip.

Basically, I socketed the 68k CPU and installed the AdSpeed there, only using
software (AUTO folder program and CPX) to control it.

Still, I totally agree with you - it's doing *something*!

Sorry I couldn't contribute to the test results in a meaningful way...

PS I do have a Lighting ST board installed, but that shouldn't make
a difference, I wouldn't think.

[ijor]

Although in my case, I did not make any alterations involving the blitter chip.

Basically, I socketed the 68k CPU and installed the AdSpeed there, only using software (AUTO folder program and CPX) to control it.

The AdSpeed manual mentions some circuit already integrated in the accelerator that involves Blitter. It is not any kind of mod that you had to perform explicitly. And your results when the accelerator is disabled does suggest that something is delaying Blitter.

[Darklord]

Oh, okay. I think you're referring to the daughterboard on some Mega ST's
for a blitter timing issue? The AdSpeed docs say it's not needed because
the AdSpeed includes the circuitry to compensate for that.

In my case, my Mega ST was one of the models that did not have a
daughterboard.

Obviously though, daughterboard or not, as we've seen, it's affecting
things.

Thanks.

[sporniket]

Anybody else? Now, after Exxos post, I would like to see the result on a standard STE and also on a standard STFM (or MegaST).

I'll try on my STe by the end of the year. (edit : hopefully sooner )

Here is my numbers. STe with blitter embedded inside MCU :

2022-12-17--blitter-test.jpg (44.46 KiB) Viewed 1662 times

[ijor]

Here is my numbers. STe with blitter embedded inside MCU :

Thanks. It confirms, once again, our previous conclusion.

[ijor]

That confirms that the weaker pull-up produces a delay. See the extra 4 cycles on tests 4-6. Again, the delay would only be significant for some blitting operations and only for code running from Rom.

Correcting myself. It is not only code from ROM that could be affected. Code from RAM might also produce a delay depending on the BGACK pull-up value. But only if the code accesses Blitter with a special sequence. Normal code is not likely to be affected.

[Cyprian]

Correcting myself. It is not only code from ROM that could be affected. Code from RAM might also produce a delay depending on the BGACK pull-up value. But only if the code accesses Blitter with a special sequence. Normal code is not likely to be affected.

I guess "Normal code" just meas start the BLiTTER with "move". But what do you mean by "a special sequence"?

[ijor]

I guess "Normal code" just meas start the BLiTTER with "move". But what do you mean by "a special sequence"?

I'll elaborate later. But it depends more on the bus activity at the end than at the start of the DMA sequence. Wait states, such as when accessing a I/O location, need to be generated for the BGACK delay to be significant.