exxos's Atari, Amiga & retro forum

Icky, great progress.

I have an idea why figures could differ between FPGA and real BLiTTER.
In short important factors are: 1) how fast the BLiTTER takes and release the bus; 2) how it interacts with the CPU in blit (non HOG) mode.

May I ask you to do four tests from attached ZIP? They should be run in ST LOW 50Hz.

Years ago I did some BLiTTER/CPU interaction tests. And based on them Hatari and Steem Teams did some tweaks their code:
http://www.atari-forum.com/viewtopic.php?p=96197#p96197
http://www.atari-forum.com/viewtopic.ph ... 23#p312823

Would be possible to take a look at the FPGA source code?

I'm putting the speed loss down to the fpga code itself. I just think a software core isn't going to be able to replicate the timing of a pure logic blitter. I mean, sure it can emulate the blitter, but its not cycle accurate and i doubt it ever can be. Not with a software core anyway.

We would have to run the blitter on a 32mhz clock and rewrite the statemachine code to emulate the ST bus cycles again. It would be as close to 100% as we could get.

I sent a PM to ijor asking for his blitter core, he says its cycle accurate so we need to try that core out more than anything . but seems ijor hasn't been around for a couple of months now..

exxos wrote: 05 Aug 2019 00:24 ... I just think a software core isn't going to be able to replicate the timing of a pure logic blitter. I mean, sure it can emulate the blitter, but its not cycle accurate and i doubt it ever can be. Not with a software core anyway...

What exactly do you mean with 'software core'?

Cyprian wrote: 04 Aug 2019 23:14 I have an idea why figures could differ between FPGA and real BLiTTER.
In short important factors are: 1) how fast the BLiTTER takes and release the bus; 2) how it interacts with the CPU in blit (non HOG) mode.

May I ask you to do four tests from attached ZIP? They should be run in ST LOW 50Hz.

Hi Cyprian.

I ran all four of your test programs and the screens are as follows. The first one the screen was shimmering around so that was the best pic I could get.

Would be interested to know your diagnosis from the tests.

Many thanks Icky,
I'm on vacations now, therefore, therefore I'll post a short note now. This evening will try to investigate that more

Tests 1st ,2nd and 4th base on the BLiTTER's copy: the Halftone Registers to the SHIFTER Color Registers. I see this mode doesn't work as expected, therefore I'm not able to judge the outcome without solving this issue. I'll skip two first tests now (I can prepare later, another variation of those tests, based on copy memory to the Sifter).

Below as comparision Hatari/Steem screenshots due to they have really good BLiTTER emulation and I have no access to my STe.

BLT_STE2.TOS:
The left side (Hatari) - how it should looks . Colored bars are the result of copying colors from the halftone register to the SHIFTER color 0 register. We can't see them on your screebshot - the right side

BLT_STE.TOS:
Each black/blue strips means the BLiTTER activity. White strips - the CPU activity. Important is when the BLiTTER starts and also when it finish. Now lets skip the second one case.

The left side (Steem) - here we can see the BLiTTER starts it exactly the same horizontal position.
On your screenshot (the right side), we see every the BLiTTER's start is moved few pixels right.
It seems either the BLiTTER's bus mastering isn't ok or the BLiTTER starts too early or too late, after being triggered by thu CPU. Or both cases are true.

exxos wrote: 05 Aug 2019 00:24I'm putting the speed loss down to the fpga code itself. I just think a software core isn't going to be able to replicate the timing of a pure logic blitter. I mean, sure it can emulate the blitter, but its not cycle accurate and i doubt it ever can be. Not with a software core anyway.

We would have to run the blitter on a 32mhz clock and rewrite the statemachine code to emulate the ST bus cycles again. It would be as close to 100% as we could get.

I would not agree with that, The BLiTTER is much simpler that the CPU, and we know FPGA CPU can be cycle exact (ijor case)

exxos wrote: 05 Aug 2019 00:24I sent a PM to ijor asking for his blitter core, he says its cycle accurate so we need to try that core out more than anything . but seems ijor hasn't been around for a couple of months now..

that would be the best move as he did a great job with cycle exact mode.

Cyprian wrote: 05 Aug 2019 09:58 It seems either the BLiTTER's bus mastering isn't ok or the BLiTTER starts too early or too late, after being triggered by thu CPU. Or both cases are true.

Very interesting thanks.. I did wonder if there was something up with the bus mastering, but I did not look into it yet, but I will do now.. But I didn't understand how that alone could cause such a huge drop in speed anyway.

Actually, looking at the code, it may just be that because the whole blitter core is running slower than it should, the bus grant will actually end up lagging anyway...

exxos wrote: 05 Aug 2019 10:56

Cyprian wrote: 05 Aug 2019 09:58 It seems either the BLiTTER's bus mastering isn't ok or the BLiTTER starts too early or too late, after being triggered by thu CPU. Or both cases are true.

Very interesting thanks.. I did wonder if there was something up with the bus mastering, but I did not look into it yet, but I will do now.

just to clarify, by "bus mastering isn't ok" I mean - it is possible that the process of taking and releasing the bus by the BLiTTER could be longer than on real hardware.

exxos wrote: 05 Aug 2019 10:56But I didn't understand how that alone could cause such a huge drop in speed anyway.

the BLiTTER has two modes of working:

1) HOG - the BLiTTER lock the bus until the blit is done. There is only two bus masterings: take the bus, release the bus.
This mode isn't GUI friendly due to the CPU is blocked therefore all interrupts are delayed;

2) Blit - the BLiTTER split the blit process into small passes: 64 bus cycles are granted to the CPU, 65 (63 + 2bus mastering) for the BLiTTER.
There is a lot of bus mastering cycles, because each pass has its own two (take and release). This mode is GUI and interrupt friendly.

The second one mode is used by the GEM.
In the debugger I see that for "Blitting" test (If I'm not wrong) Gembench does 1212 blits. Each has (XCount=14, YCount=51) 1428 memory accesses, it is 22,7 pass ber blit .
121* 22,7 = 27472 pass per test. Each pass with two bus masterings: take, release. This could have huge impact onto final figures.

Actually, Steem debugger shows me more than the BLiTTER 67000 passes in that test.

From what I understand (from variable names etc.) this is the Suska implementation of the blitter?

As this works fine in the Suska board itself, I would assume the problems have something to do with the integration of the IP core.