little Blitter benchmark demo

[leonard]

22 sprites, cool Working on my STFM $1B is 27 sprites

$1b is 27 for sure but 22 is 3 bitplans sprites, not 2. That's why I suggest Frank to add a three bitplan sprite to its benchmark so we can compare with generated code of existing demos.

[exxos]

22 sprites, cool Working on my STFM $1B is 27 sprites

$1b is 27 for sure but 22 is 3 bitplans sprites, not 2. That's why I suggest Frank to add a three bitplan sprite to its benchmark so we can compare with generated code of existing demos.

ahhh yep, good point

[AtariZoll]

...
Yep I am using TOS104, Wasn't there some cookies needed to use the blitter on some programs ?

Cookies were introduced with TOS 1.06 - they are there only to inform, not to use for HW access . There is XBIOS call to test blitter presence - at TOS 1.02, since it is first what supports blitter .

[leonard]

There is XBIOS call to test blitter presence

Yes that's the safest way. Anyway I prefer people testing with hardware register and bus error, just because of SainT issues I explain: I always use SainT with old TOS 1.0 just because it's the best compatible TOS with SainT. As SainT supports STE hardware, STE demos are running fine, even with TOS 1.0.
Program testing blitter using TOS won't work on my strange SainT configuration. ( I admit this is not a problem, just to say )

[AtariZoll]

...
Yes that's the safest way. Anyway I prefer people testing with hardware register and bus error, just because of SainT issues I explain: I always use SainT with old TOS 1.0 just because it's the best compatible TOS with SainT. As SainT supports STE hardware, STE demos are running fine, even with TOS 1.0.
Program testing blitter using TOS won't work on my strange SainT configuration. ( I admit this is not a problem, just to say )

I must say that I find this best compatibility with TOS 1.00 little strange. If blitter emulation is OK, it should work well with 1.02, 1.04 at least.
No other HW extra support in TOS 1.02 and 4 . TOS 1.00 is just slow and problematic with 4 MB RAM . Will not continue list of drawbacks

[Frank B]

Pepera the demo uses preshifting. The blitter is still substantially faster there. Even using preshifting you can't beat the blitter for a true masking sprite. As for code gen, well are we sure there is not cheating going on there? How much cheating would I be allowed to do?

Could I

1) limit the window size and clear all bobs in one pass?
2) copy and not mask the first sprite?
3) inline every function call?
4) precalculate all the coordinate tranforms?
5) align all the sprite data on a 64 kb boundary to save setting the high word of the source address?

I've got an older version with 2 and 3 done.. It does 31 bobs a frame but the code is a mess. I've calculated the max throughput for that size of sprite is 35 bobs a frame excluding bus arbitration. Here are the figures for a 3 plane 32*32 sprite excluding bus arbitration.


Source data is 3 words wide 3 planes deep and 32 lines high.

That's 3 columns wide

r/m/w | r/m/w | m/r
3 + 3 + 2 = 8 bus cycles per plane per line for mask.
3 + 3 + 2 = 8 bus cycles per plane per line for sprite data
16 in total for masking

* 3 planes = 16 * 3 cycles per line = 48 bus cycles
* 32 high = 1,536 bus cycles per bob

clear is
3 words wide per plane * 32
w / w / w * 3 * 32 = 288 bus cycles per bob
3 columns * 3 planes * 32 lines

so excluding set up time we have a total cost of
288 + 1536 = 1,824 bus cycles

There are 40 thousand bus cycles per frame
160,000 / 4 = CPU -> bus cycles

40,000 / 1,824 = 21.9 bobs a frame

[Frank B]

I tested on Hatari in stfm config using tos 2x. There is no specific check for the blitter yet. It is more likely I've missed an ste register I will look later when less jet lagged. edit: It works on that config in hatari but not on the real hw. More testing/bugfixing when I'm not jet lagged

[Frank B]

If the sprite is 32*31 in three planes the max theoretical through put will be slightly higher.

3 columns wide sprite

r/m/w | r/m/w | m/r
3 + 3 + 2 = 8 bus cycles per plane per line for mask.
3 + 3 + 2 = 8 bus cycles per plane per line for sprite data
16 in total for masking

* 3 planes = 16 * 3 cycles per line = 48 bus cycles
* 31 high = 1,488 bus cycles per bob

clear is
3 words wide per plane * 31
w / w / w * 3 * 32 = 279 bus cycles per bob
3 columns * 3 planes * 31 lines

so excluding set up time we have a total cost of
279 + 1488 = 1,767 bus cycles

There are 40 thousand bus cycles per frame
160,000 / 4 = CPU -> bus cycles

40,000 / 1,767 =22.6 bobs a frame


Now let's look at the clear routine. It is clearing each sprite individually at 279 bus cycles a bob. That's 22 * 279 == 6,138 bus cycles (words cleared).
There's 32000 bytes in a screen which is 8000 bytes per plane or 4000 words. If I limited the bob movement to half the screen I'd only need to clear 4000 words. That would allow for more bobs. Some of these optimisations are a bit silly though. I'd prefer general purpose code which could be used in a game.

[exxos]

I tested on Hatari in stfm config using tos 2x. There is no specific check for the blitter yet. It is more likely I've missed an ste register I will look later when less jet lagged. edit: It works on that config in hatari but not on the real hw. More testing/bugfixing when I'm not jet lagged

Try TOS104 Actually I would have thought checking for the blitter or not was not a huge thing, as it would just crash without a blitter or something, though the blitter is there in my STFM, and working with that other demo. So can't be much wrong

[Frank B]

I tested on Hatari in stfm config using tos 2x. There is no specific check for the blitter yet. It is more likely I've missed an ste register I will look later when less jet lagged. edit: It works on that config in hatari but not on the real hw. More testing/bugfixing when I'm not jet lagged

Try TOS104 Actually I would have thought checking for the blitter or not was not a huge thing, as it would just crash without a blitter or something, though the blitter is there in my STFM, and working with that other demo. So can't be much wrong

I did It is likely a bug on my side which doesn't show up in the emulator. How much RAM do you have? Can you post a video?

[exxos]

I did It is likely a bug on my side which doesn't show up in the emulator. How much RAM do you have?

My STFM has 4MB

[leonard]

40,000 / 1,767 =22.6 bobs a frame

I agree with all your calculation, but 22.6 is theorical speed, without blitter setup. For a 32*31 sprite, blitter setup time per sprite is not small, so you can remove maybe one or two sprites if you take setup in account. More than that: your calculation is sprite clear and draw only ! In the MCoder demo you don't count the curve calculation and the 4 pixels 1 plan scroller. (you can forget the music because it's pre-rendered).

Honestly I think it will be really hard to beat MCoder sprite demo using blitter on STE.

[Frank B]

40,000 / 1,767 =22.6 bobs a frame

I agree with all your calculation, but 22.6 is theorical speed, without blitter setup. For a 32*31 sprite, blitter setup time per sprite is not small, so you can remove maybe one or two sprites if you take setup in account. More than that: your calculation is sprite clear and draw only ! In the MCoder demo you don't count the curve calculation and the 4 pixels 1 plan scroller. (you can forget the music because it's pre-rendered).

Honestly I think it will be really hard to beat MCoder sprite demo using blitter on STE.

Possibly but we're comparing general purpose code against demo code I bet there is some serious cheating going on. Is the third plane the same size as the first two?'

It would be trivial for me to animate each bob for instance. I suspect his is hard coded
See my point about limiting the screen area too. I believe his demo does this so I could claw back some time there.

There's a comment on the thread saying the sprite is mostly 2 planes with a tiny bit in the third plane.. probably the eyes
Can I cheat like that too and limit the size of the 3rd plane?

[Frank B]

I tested on Hatari in stfm config using tos 2x. There is no specific check for the blitter yet. It is more likely I've missed an ste register I will look later when less jet lagged. edit: It works on that config in hatari but not on the real hw. More testing/bugfixing when I'm not jet lagged

Try TOS104 Actually I would have thought checking for the blitter or not was not a huge thing, as it would just crash without a blitter or something, though the blitter is there in my STFM, and working with that other demo. So can't be much wrong

Adding a specific test for the blitter is on the todo list. edit: I'll add a bus error handler access for those using saint

[leonard]

I must say that I find this best compatibility with TOS 1.00 little strange. Will not continue list of drawbacks

I totally agree with you. My bad for those TOS incompatibility in SainT. The main problem is that I never really investigate to fix TOS emulation problems I'm focused on making demos more compatible. I know the many TOS incompatibility and lack of HDD support make people prefer other emulators.
Anyway I personnaly use SainT to see old demos just because of the CRT video emulation and gamma correction. Looking at an old demo with floppy sound and CRT emulation is priceless

[AtariZoll]

Well, I will not go here in some calculations, but will do some test proggie little different:
Low res, with typical 4bpp, masked sprite of 32x32 px . I did already some code for drawing with CPU, so need only blitter code.
Will use some picture as background - then saving background in detail before draw is mandatory .
Or maybe just 16x32 px sprites - that would match better 32x32 in medium res.

[Frank B]

Well, I will not go here in some calculations, but will do some test proggie little different:
Low res, with typical 4bpp, masked sprite of 32x32 px . I did already some code for drawing with CPU, so need only blitter code.
Will use some picture as background - then saving background in detail before draw is mandatory .
Or maybe just 16x32 px sprites - that would match better 32x32 in medium res.

Well if you're confident you can match the blitter with preshifting I can spec the function for you to write. We can plug it in and compare.
I'm pretty confident my preshift function is fast and the blitter is much quicker. You can test this with 3 and 4 keys in the intro.

$19 hex vs $13 for the CPU preshifter. That's nowhere near as fast as the blitter The coordinate calcs and function call overhead is the same on both functions. It's a valid apple to apple comparison.

[Eero Tamminen]

It is likely a bug on my side which doesn't show up in the emulator.

Sounds like bug in Hatari. Which version you're using? Can you give more details on what worked in Hatari, but not on real HW?

[Frank B]

Hi. I don't know the details yet as I haven't reproduced the issue on real hardware yet. Will let you know as soon as I've fixed it.

[exxos]

Right, so the V7 one I confirm is working on TOS104 STFM. For some reason the program was quitting during loading, despite I still had previous versions on my floppy and despite re-copying it form the zip to floppy.. strange.. but magically started working again

Anyway, No bugs other than when it goes over to 2VBL the screen starts juddering, I can't see anything else wrong at first glance

[qq1975b]

V.7 on a:

STe 1.62 SP TOS: VBL $01 Bob count: $19 and BLITTER renderer active
MSTe 2.06 UK TOS: VBL $01 Bob count: $19 and BLITTER renderer active: Same

If needed I can test it later on a Mega ST 1.04 TOS...is it?

[Frank B]

Right, so the V7 one I confirm is working on TOS104 STFM. For some reason the program was quitting during loading, despite I still had previous versions on my floppy and despite re-copying it form the zip to floppy.. strange.. but magically started working again

Anyway, No bugs other than when it goes over to 2VBL the screen starts juddering, I can't see anything else wrong at first glance

Cool

By juddering do you just mean a lowered framerate or is there some corruption?

[Frank B]

V.7 on a:

STe 1.62 SP TOS: VBL $01 Bob count: $19 and BLITTER renderer active
MSTe 2.06 UK TOS: VBL $01 Bob count: $19 and BLITTER renderer active: Same

If needed I can test it later on a Mega ST 1.04 TOS...is it?

Thanks Yeah, it should work on any blitter capable ST now. It'll bus error on non blitter machines. I'll need to add a check for this.
So the next step after this is adding an 030 renderer, a greetings update and some optimisation.

[exxos]

By juddering do you just mean a lowered framerate or is there some corruption?

I mean the entire screen seems to jump upwards and then back down again when it gets on 2VBL.. I can try and take a video...

http://exxoshost.co.uk/temp/DSCN2371.avi (156MB)

Its odd, as if you watch the speed of the bobs from about 1:10, then about 1:20 they actually speed up for a couple seconds, then go back to normal speed again... odd..

[Frank B]

By juddering do you just mean a lowered framerate or is there some corruption?

I mean the entire screen seems to jump upwards and then back down again when it gets on 2VBL.. I can try and take a video...

http://exxoshost.co.uk/temp/DSCN2371.avi (156MB)

Its odd, as if you watch the speed of the bobs from about 1:10, then about 1:20 they actually speed up for a couple seconds, then go back to normal speed again... odd..

Oh that's odd. It looks like the text is jumping from frame to frame!

Anyone else seeing this? Perhaps the vbl is being delayed and the video base registers aren't being updated in time. If it happens even if one bob is active it might be the alignment is wrong on one screen. More bugs to fix I think

The speed up is just because the teletype is paused and not printing chars just before the fade In that case it does 27 bobs a frame