little Blitter benchmark demo

[lotek_style]

There you go:

http://demozoo.org/productions/144488/

[AtariCrypt]

The most under-used part of the ST family.. shame. Your benchmarking demo is an eye opener. Thank you

[npomarede]

I just had a brainstorming session with Doug. I think we worked out what the issue is. I think the real hardware clears both the busy bit and the bus sharing bit at the end of each blit. The hog mod state doesn't persist from blit to blit. It needs to be set each time. If this is the case it would explain the code running at half speed. It would also be a bug in both Hatari and steem. My wifi at this airport is horrible. I may not be able to upload the next build.

it really make sense! I'll test your new version when you post. Btw I always prefer using move.b #$c0,$8a3c instead of bset #7,$8a3c

Hi,
I confirm this ; under Hatari 1.8 I get $19 blitter sprites, but after clearing HOG bit at the end of a transfer, I get the same problems you reported on real HW :
- with 1st version, sprites are not correctly cleared
- with 3rd version, only $11 sprites get displayed per VBL instead of $19
People interested can get the latest Hatari dev sources, else it will be included in next Hatari 1.9.

Nicolas

[Frank B]

Brilliant. Thanks

[AtariZoll]

Yes, on real HW HOG bit is cleared after done, while in Steem 3.2 is not.
What is really interesting is how that this emulation error went unnoticed over years. I'm pretty sure that reason is simple: noone of blitter coders expected that HOG bit will stay set, so naturally set it always together with BUSY bit when start blitter. What btw. costs nothing. You just write $C0 there instead $80 .

[Frank B]

I assumed it would be set. Previous experience on the Amiga.
In any case the behaviour isn't documented. It is now

[Frank B]

There you go:

http://demozoo.org/productions/144488/

Cool. I will upload a working on real hardware version soon. Having a nice steak at the airport first coding food!

[Frank B]

The next version will also be a bit faster.

[Frank B]

BLTBNCH4.TOS.zip

Ok here's the fixed version. People please post your results on real hardware along with if your machine is pal/ntsc or vga.

Screen Shot 2015-08-27 at 17.04.44.png

It would be cool to see if there is any variance across STe models. I'll fix this for the STFM next and post an updated version. Next week probably.

I'll add a greeting for Leonard and ppera too on build 5. You did the testing Thanks!

[exxos]

Got there in the end

1.jpg

Any more bob's and it slows down and then goes to 2 VBL's.

This is on a stock STE TOS 1.62. I don't have my STFM with blitter hooked up, but if there is still tweaking to do for STFM version, then works out well for me

EDIT: Actually it can do 1B bobs in 1 VBL, but the bobs actually slow down after 1A it seems.

[npomarede]

I assumed it would be set. Previous experience on the Amiga.
In any case the behaviour isn't documented. It is now

By the way, if we want to be complete, there're 2 cases where busy bit is cleared :
- at the end of a transfer, as in your case
- "immediately" if line count at $FF8A38 is 0 when blitter is started
In both cases, I now clear hog bit too in Hatari.

But for 2nd case, some checks could be made on real STE :
- if line count is 0, how many cycles are taken after a write to FF8A3C ? Does the blitter tries to take the bus anyway and gives it back just after ? (I guess it's the case)
- in that case, is hog bit cleared too ? If there's only 1 common path in the blitter, then it should be. But maybe the blitter has a special case if line==0 at start ?

Nicolas

[Frank B]

Yeah.. I need to do some optimisation yet The original could do 30 a frame. The theoretical max is 35.
I'm also seeing it lie about the frame count sometimes in the emulator.. More bugs to fix. That said, here comes the STFM and Falcon compatible version. Enjoy

[Frank B]

I assumed it would be set. Previous experience on the Amiga.
In any case the behaviour isn't documented. It is now

By the way, if we want to be complete, there're 2 cases where busy bit is cleared :
- at the end of a transfer, as in your case
- "immediately" if line count at $FF8A38 is 0 when blitter is started
In both cases, I now clear hog bit too in Hatari.

But for 2nd case, some checks could be made on real STE :
- if line count is 0, how many cycles are taken after a write to FF8A3C ? Does the blitter tries to take the bus anyway and gives it back just after ? (I guess it's the case)
- in that case, is hog bit cleared too ? If there's only 1 common path in the blitter, then it should be. But maybe the blitter has a special case if line==0 at start ?

Nicolas

Yep. More investigation required. Another question. Is the behaviour the same in all models?

[Frank B]

Yeah.. I need to do some optimisation yet The original could do 30 a frame. The theoretical max is 35.
I'm also seeing it lie about the frame count sometimes in the emulator.. More bugs to fix. That said, here comes the STFM and Falcon compatible version. Enjoy

I can see when it lies about the frame count.
The logic looks like this

1.sample frame tick
2. do work
3. calculate elapsed frames
4. int to str -> draw them to the screen...

It looks like 4 can push it over the 1 vbl *after* it's sampled the timer.
Should be easy enough to fix.

[Frank B]

Yet another bug to fix.
I should initialise the clear list to point to aligned addresses on the screen.
If not then the wrong planes could get cleared corrupting the teletype. Bugs always cluster

[Frank B]

Here's a new build I worked on while flying.

This build is

a) Falcon and ST compatible. Screens are allocated on a multiple of 256
b) Contains a fix for screen redraws when reducing bob count
c) no longer lies about the frame count.
The code sampled the vbl tick and printed the difference on the screen.
If the VBL occurred during the OSD update it reported the wrong count.
d) There's a new transition on the bobs when starting/quitting

I guess I'll need to update the build on demooz too
It's not finished yet. I want to add a 12 bit fade, 030 renderer and check for the presence of the blitter on start up. Way too fried with jet lag to do that today,

Update: build 6 breaks the cpu preshifter code... oh well I'll fix that when I'm not so jetlagged,

[exxos]

V6 shows $1A bobs, all is well, $1B and 2 VBL and slow down, but also you seem to have a new bug as the whole screen jumps vertically

[Frank B]

Crash fixed

[Frank B]

V6 shows $1A bobs, all is well, $1B and 2 VBL and slow down, but also you seem to have a new bug as the whole screen jumps vertically

Heh.. yes. that's the new transition in/out. I'll add acceleration to it in a bit. The new build fixes a crash with the CPU clear. Wrong register being used for a loop I'll start optimising it when I've recovered from jet lag.

Btw play with the function keys..you can get some crazy patterns

[exxos]

Seems to run the same as V6. Interesting program for sure, defiantly does bobbing better than CPU it seems.

I think my STFM with blitter has my V1 booster in there, Don't know if that will upset anything in your code ? Blitter still runs at 8mhz, but not sure if it will have any "side effects" with your benchmark.. I will try and solder in a blitter in a stock machine later today if needs be...

[leonard]

Interesting program for sure, defiantly does bobbing better than CPU it seems.

I like the blitter too, but to compare with CPU I think that a "generated code" section must be added. Blitter is obviously faster than CPU for sprite if you can't preshift. But if you have enough memory to preshift (always the case in demos), then you have enough memory to use generated code. And in that case, I'm not sure blitter can beat CPU, even for 32*32 sprites.

There is really few demos with 2 bitplans sprites. generally it's 3 or 4. Maybe Franck could add a 3 bitplans sprites in its benchmark. To compare with CPU, that demo is cool : http://www.pouet.net/prod.php?which=29317
-it uses 32*31 sprites, 3 bitplans ( anyway 11 lines of the sprite are 2 bitplans )
-it uses real time curve (as in the benchmark)

[AtariZoll]

RAM speed is what is real limiting factor in all this. Good CPU code with preshifts can achieve aprox. same speed as blitter. Because in both cases most of time will go on RAM access - about 70-85% . So, real benefit of blitter is to save some RAM and make coding easier.

But there may be some special cases, what are almost impossible to solve with CPU only - unless it is very fast. Preshifting large backgrounds, maps can not fit even in 4 MB RAM in some cases - then solution would be preshift on-fly - hard to code, and depends from free CPU time.

Some games change background according to player's actions, and even may draw moving enemies on background buffer, before it will be drawn on screen - that may save some CPU time, because then must not draw it for every frame, only when change occurs. Then no preshift, so only blitter can solve fine scroll enough fast , or in case of STE the STE HW scroll. But with blitter it is actually simpler.

[exxos]

Interesting program for sure, defiantly does bobbing better than CPU it seems.

I like the blitter too, but to compare with CPU I think that a "generated code" section must be added. Blitter is obviously faster than CPU for sprite if you can't preshift. But if you have enough memory to preshift (always the case in demos), then you have enough memory to use generated code. And in that case, I'm not sure blitter can beat CPU, even for 32*32 sprites.

There is really few demos with 2 bitplans sprites. generally it's 3 or 4. Maybe Franck could add a 3 bitplans sprites in its benchmark. To compare with CPU, that demo is cool : http://www.pouet.net/prod.php?which=29317
-it uses 32*31 sprites, 3 bitplans ( anyway 11 lines of the sprite are 2 bitplans )
-it uses real time curve (as in the benchmark)

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

@FrankB - Your program starts to load then just quits back to desktop on my STFM with blitter

[dml]

@FrankB - Your program starts to load then just quits back to desktop on my STFM with blitter

The blitter existence test might be TOS based rather than HW register based? I suppose Frank will know what kind of test he used

[exxos]

@FrankB - Your program starts to load then just quits back to desktop on my STFM with blitter

The blitter existence test might be TOS based rather than HW register based? I suppose Frank will know what kind of test he used

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