New Atari STE Blitter objects demo (24 Bobs)

[Cyprian]

If you have 256 pixels available vertically I suppose you have opened both upper and low border ? (on STe if I well understand the resolution is 273 when vertical borders are opened)

In order to open left additionnal 16 pixels you just have to write just once (in a shifter "safe" place) something like :
move.b #1,ffff8265.w
clr.b ffff8264.w

Thanks. Yes, that works. Here's a screenshot @ 336 x 273:

new binary please

[terence]

generated code did quite the same, 25 balls, in may 1991, on a ST ( not STE )

https://youtu.be/uiHPS1ny-Qk?t=40

( i don't remember what is the exact size of the balls, and there is no open border )

[SteveBagley]

it could be connected with the fact that Mega STE's BLiTTER takes 1 more bus cycle (4 CPU 8Mhz cycles) per every pass

I've heard this mentioned before and always wondered why this should be the case -- the STE and MegaSTE use the same Blitter chip don't they (either an external chip, or as part of the COMBO chip.

I guess it would be down to the implementation of the cache since it would presumably need to invalidate any cached data the Blitter has modified -- but I'd have thought that would have been disabled when the cache was inoperative. Looking at the schematic for the MegaSTE, the CPU's BG is taken into the PAL U002 and the rest of the circuit fed (as XCPUBG) from U011 -- presumably this always delays BG by a clock cycle, and I guess for anything else using BR/BG (DMA transfers?) too…

Steve

[Cyprian]

generated code did quite the same, 25 balls, in may 1991, on a ST ( not STE )

https://youtu.be/uiHPS1ny-Qk?t=40

( i don't remember what is the exact size of the balls, and there is no open border )

25 boobs 29x29 in 3 bitplanes, Anima: 24 boobs 32x32 in 4bitplanes

it could be connected with the fact that Mega STE's BLiTTER takes 1 more bus cycle (4 CPU 8Mhz cycles) per every pass

I've heard this mentioned before and always wondered why this should be the case -- the STE and MegaSTE use the same Blitter chip don't they (either an external chip, or as part of the COMBO chip.

I guess it would be down to the implementation of the cache since it would presumably need to invalidate any cached data the Blitter has modified -- but I'd have thought that would have been disabled when the cache was inoperative. Looking at the schematic for the MegaSTE, the CPU's BG is taken into the PAL U002 and the rest of the circuit fed (as XCPUBG) from U011 -- presumably this always delays BG by a clock cycle, and I guess for anything else using BR/BG (DMA transfers?) too…

I checked the BLiTTER timing from programmer point of view and that on additional bus cycle is spent for bus arbitration, therefore your theory with the cache sounds reasonable.

[terence]

with holes in the sprites, such as letters, generated code beats blitter !

[joska]

with holes in the sprites, such as letters, generated code beats blitter !

Maybe relevant for huge sprites with huge holes, but not in the general case.

[Anima]

with holes in the sprites, such as letters, generated code beats blitter !

Do you have any examples like an sprite image you can provide? Or perhaps any code snippet for drawing a line?

Using "sprites" up to 32 pixels there's no way that code will be faster.

[1st1]

I just tested it on my 1040STE, wow, looks really great. I hope there will be a new big megademo using this new blitter algorythm.

[terence]

with holes in the sprites, such as letters, generated code beats blitter !

Do you have any examples like an sprite image you can provide? Or perhaps any code snippet for drawing a line?

Using "sprites" up to 32 pixels there's no way that code will be faster.

Electra Demo ?
one of the last Equinox demos if i remember well.

[Cyprian]

with holes in the sprites, such as letters, generated code beats blitter !

Do you have any examples like an sprite image you can provide? Or perhaps any code snippet for drawing a line?

Using "sprites" up to 32 pixels there's no way that code will be faster.

Electra Demo ?
one of the last Equinox demos if i remember well.

I think that the CPU could beat the BLiTTER only in case of small sprites e.g. 12x12. Bigger sprites even with holes will be faster with the BLiTTER:
https://www.youtube.com/watch?v=FRetovtonyY

[terence]

i'm not good at blitter at all, i only coded on ST in the times when demos had to run on old STF and even ST (without F)

but using generated code , you simply jump over holes, doing nothing, just an ADD ( addq most of the times)

i think that the blitter keeps on doing his stuff, reading and writing RAM changes, even when dispaying nothing

so it seems difficult to beat generated code in these cases

https://youtu.be/nFm4VUR6EBY?t=192

[thomas3]

Plus you can skip masking when not needed in generated code.
And use immediates if you're willing to take the memory hit, so you save on reads
Generated code rules!

[Cyprian]

i'm not good at blitter at all, i only coded on ST in the times when demos had to run on old STF and even ST (without F)

but using generated code , you simply jump over holes, doing nothing, just an ADD ( addq most of the times)

i think that the blitter keeps on doing his stuff, reading and writing RAM changes, even when dispaying nothing

so it seems difficult to beat generated code in these cases

https://youtu.be/nFm4VUR6EBY?t=192

I see there only 7 bobs in 3 bitplanes vs 10 bobs in 4bitplanes https://www.youtube.com/watch?v=FRetovtonyY

regarding 'generated code' it is also used in case of the BLiTTER in order to speed up blitting and skip empty spaces


Anyway I really like that screen - stars with flying letters.
I've grabbed the demo from there https://www.pouet.net/prod.php?which=11808 Unfortunately the demo bombs out on the second screen.

[Anima]

but using generated code , you simply jump over holes, doing nothing, just an ADD ( addq most of the times)

Plus you can skip masking when not needed in generated code.
And use immediates if you're willing to take the memory hit, so you save on reads

I know what you mean.

Well, the current state of the Endmask-Blitter is that it uses generated code as well to cover the whole sprite area so even holes will be skipped.

The advantage is that you need only a very small setup code to draw chunks (lines) of the sprite. The Blitter itself draws only what needs to be drawn. Please note: even masking will be skipped automatically by the Blitter due to the simple copy function issued by Endmask = $ffff.

So consider this as a generated code drawing without the cycles spend for CPU instruction fetches needed to do the AND and OR operations. In fact this is generally faster in every aspect.

[metalages]

with holes in the sprites, such as letters, generated code beats blitter !

Better holes management versus not having to feed the opcode to process each transfer. Also using the endmask does the and / or stuff in one pass.

[Anima]

new binary please

http://www.atomic-skulls.de/temp/atari/336x273.prg

[Cyprian]

new binary please

http://www.atomic-skulls.de/temp/atari/336x273.prg

thanks

[Eero Tamminen]

http://www.atomic-skulls.de/temp/atari/336x273.prg

Thanks, this looks much nicer (symmetrical) in Hatari now that both top & bottom borders are removed completely!

[Anima]

Thanks, this looks much nicer (symmetrical) in Hatari now that both top & bottom borders are removed completely!

Yes. This version is "calibrated" for Hatari.

Testing and recording a video on real hardware was the intention of the first version. For this version I think I'll have to tune my SC1224 monitor a bit.

[Anima]

new binary please

http://www.atomic-skulls.de/temp/atari/336x273.prg

Here's a short video about how it looks like on the Atari SC1224: https://www.youtube.com/watch?v=pdOh0QyC1Sg