Free Form Sprite Layer example + source

[roondar]

This is very interesting, it may indeed be possible to do a 15 colour AGA free form sprite layer then. I’ll do some more tests for sure!

[Tigerskunk]

@Roondar: Damn, i should think properly before posting. You are right off course, in that you need double amount of repositionings then with attached sprites...

Fascinating demonstration.

It's amazing that the OCS Amiga gets more possibilities after 30 years of existing.

[Toni Wilen]

Unfortunately there is annoying side-effect that explains the gap.

If 64-wide sprite is being drawn and FMODE is changed (32-wide or 16-wide), right most 32-pixel part of sprite is not drawn.

It is easy to see by clearing FMODE and then immediately writing again with original value. Short part of sprite disappears if FMODE was changed during 64-wide sprite when it was drawing rightmost 32-pixel part of sprite. It does not affect leftmost 32-pixel part of sprite.

EDIT: Strangely there is large "delay", if fmode is changed near the beginning of sprite, it affects beginning of last 32-pixel part and so on..

EDIT2: I think Lisa has 2x32-bit sprite shift registers (per sprite) and when bits are output to display, other side of register gets new bit from another 32-bit shift register that contains last 32 pixels of 64-wide sprite and interface between first and second shift registers is active only if FMODE 64-bit sprite is enabled. It would explain "delayed" behavior. Emulating this gets really tricky..

EDIT3: Above logic creates identical display, at least when running SPR_Layer_AGA.zip. Some optimizations and cleanups to do.

[ross]

And changing from 32bits->16bits? (with single 32 bit CAS or double 16bit CAS)

[Toni Wilen]

Originally Posted by ross

And changing from 32bits->16bits? (with single 32 bit CAS or double 16bit CAS)

It seems to only affect 64-wide sprites.

[Toni Wilen]

winuae.7z updated, at least SPR_Layer_AGA.zip produces correct display.

[ross]

Originally Posted by Toni Wilen

EDIT2: I think Lisa has 2x32-bit sprite shift registers (per sprite) and when bits are output to display, other side of register gets new bit from another 32-bit shift register that contains last 32 pixels of 64-wide sprite and interface between first and second shift registers is active only if FMODE 64-bit sprite is enabled. It would explain "delayed" behavior. Emulating this gets really tricky..

This absolutely make sense.

Originally Posted by Toni Wilen

winuae.7z updated, at least SPR_Layer_AGA.zip produces correct display.

Thanks

[roondar]

I did a bunch more experiments and though I'm sure I can't add much new info, perhaps it is still useful to know the results.

It seems it is actually possible to change FMODE in such a scanline position that no gap seems to be visible*. However, any SPRxDATA/B values written prior to the FMODE change seem to vanish (as in, I only got empty pixels for any sprite channel I wrote data to with the Copper before the FMODE change). Only changes after writing to FMODE seem to actually be propagating.

In other words, I can reset the sprite width to 16 pixels wide, but because the writing to SPRxDATA/B needs to happen after the reset there is never enough time to actually create that sprite layer I hoped to achieve.

*) it seems that an update to FMODE after the last words (i.e. pixels 48-63) of a sprite have started drawing does not cause a gap. I've not tested this in great detail, but this is what seems to be the result of at least one of my tests.

[Toni Wilen]

Originally Posted by roondar

In other words, I can reset the sprite width to 16 pixels wide, but because the writing to SPRxDATA/B needs to happen after the reset there is never enough time to actually create that sprite layer I hoped to achieve.

I didn't test SPRxDATx writes but it is possible copper/cpu write to SPRxDATx do nothing or write garbage if FMODE is set to 32 or 64 wide sprites.

*) it seems that an update to FMODE after the last words (i.e. pixels 48-63) of a sprite have started drawing does not cause a gap. I've not tested this in great detail, but this is what seems to be the result of at least one of my tests.

In my tests FMODE change is safe during last 32 pixels. You can easily confirm that there is no other side effects by writing to FMODE back to back, first write sets sprite to 16 or 32 wide, then back to 64 wide: sprite should have has small gap in last 32 pixel part but some pixels still remaining.

[ross]

Originally Posted by Toni Wilen

I didn't test SPRxDATx writes but it is possible copper/cpu write to SPRxDATx do nothing or write garbage if FMODE is set to 32 or 64 wide sprites.

I seem to remember that in an old thread someone had done some tests and reported the results, but we would have to find it..

EDIT: I did not find anything (I may have remembered badly), then you have to try

[Toni Wilen]

I did some 64 pixel wide SPRxDATx write test. Results are very unexpected..

If MOVE to SPRxDAT is done immediately after WAIT that has horizontal position xF, write works differently than any other position! It is not relative to sprite start position (of course as long as sprite start is later), sprite start can be moved and it does not affect this really strange behavior.

xF = First 32 pixels contains same duplicated 16 bit pattern. This is not what was written, no idea where this comes from (possibly whatever was in upper 16 bits in data bus?). Last 32 pixels are written 16 bit pattern duplicated.

Any other hpos = first 16 pixels contain something. Following 48 pixels are written 16 pixel word * 3.

This needs much more testing..

EDIT: xF thing probably is related to bit plane DMA. (I had single plane enabled)

[roondar]

That's very interesting. Writing to SPRxDATx when FMODE is 4x sprite width then does give you the pattern you write, but more than once. And with added garbage.

However, that does give me an idea. If it is the case that 64 pixel sprites always result in at least the last word of the sprite getting the desired pattern when SPRxDATx is written by the copper, then a 15 (rather than 16) colour sprite background should do doable:

0) set FMODE to sprite width = 64px and never switch it.
1) display all sprites attached side by side (covering 256 pixels), starting with pair 6/7 and ending with pair 0/1
2) shift position of all sprite channels other than 0/1 such that the last word of each sprite pair covers the next 16 pixels after the first 256 (i.e. last 16 pixels of a pair at pixel positions 256, 272, 288) - this gives a 304 pixel wide screen*.
3) do this shift in such a way that priorities end up with each new sprite added having a lower priority than the pair immediately to it's left but higher than the one immediately to it's right. (i.e. sprites 2/3 at position 256, sprites 4/5 at position 272 and sprites 6/7 at position 288)
4) make sure that all sprites never have any transparent pixels so all the garbage pixels get covered by the higher priority sprites.
5) update SPRxDATA/B as required with the new 16 pixel pattern desired.

This should, if my assumptions above are correct, give a 15 colour sprite based background layer on AGA up to 304 pixels wide*. And, thanks to the lack of FMODE switching required, the timing should be flexible enough to allow for this even when using a screenmode with a high bitdepth.

So, this all gives me something new to try out

*) Depending on how background scrolling is handled this may drop to 288 pixels wide.

[ross]

Originally Posted by roondar

..then a 15 (rather than 16) colour sprite..

Actually 14

When you wrote this I immediately understood what you wanted to do.
Well, using black colored solid pixel in place of the transparent is clever (a trick usable on several occasions to 'cover' glitches).
You can even simulate copper gradient changing it instead of COLOR00.
You cannot use sprites layer for the foreground but who cares

[roondar]

Originally Posted by ross

Actually 14

I'm covering the 16th colour (i.e. 'transparant' or background colour) with one of the 15 other colours. This doesn't actually lose me the colour I use to cover the transparency with, so I can actually use all 15 colours

When you wrote this I immediately understood what you wanted to do.
Well, using black colored solid pixel in place of the transparent is clever (a trick usable on several occasions to 'cover' glitches).
You can even simulate copper gradient changing it instead of COLOR00.
You cannot use sprites layer for the foreground but who cares

Indeed, nothing says '8/16 bit development' like some covering of glitches caused by abusing hardware features in ways unintended

[roondar]

So, I've tested out my idea where I block out any 'garbage' created by the sprite data reloading with higher priority sprite data. And it works - behold the 15 colour 'free form' sprite background layer (AGA only)

Attached are two screenshots (one from a real A1200 and one from WinUAE) and the test executable. Note that the test executable is a hacked version of the OCS sprite layer program and as such does all sorts of stuff that is not needed (such as swapping copper lists and updating playfield shift).

While nothing is moving and the screen is really quite dull to look at, what is seen on screen is only attached sprites (no bitplane data)*, where the last two sprites had their sprite data updated.

In it's current form, the effect would be limited to 304 pixels wide (static) or 288 pixels wide (scrolling). It is probably possible to position the 64 pixel sprites and 16 pixel reloaded ones in such a way that a wider screen is possible (for instance by reloading one sprite pair twice (or more) and 'sandwiching' it between two higher priority 64 pixel sprites) but I only thought of this as I'm typing this post so that's not in the current example.

I'll probably do a nicer program with some prettier graphics at one point, but for now this proof of concept will have to do



*) There is bitplane data, but it's all colour zero (=black)

[Toni Wilen]

I tested if there is some pattern in 64 pixel wide sprite behavior when writing to SPRxDATA using copper.

And there is but it is quite strange..


Test copper list

...
$60HH $FFFE
$0180 test color start
$0144 $FFFF
$0180 test color end

I tested HH from $41 to $63 and wrote down on screen visible bit pattern of first 16 pixels of sprite (last 48 becomes FFFF as expected)

41 0000000101000100 0144
43 1010001100000000 A300
45 0110000001001110 604E
47 0000000101000100 0144
49 0000000101000100 0144
4B 0000000101000100 0144
4D 1010001100000000 A300
4F 0110000001011000 6058

51 0000000101000100 0144
53 0000000101000100 0144
55 0000000101000100 0144
57 1010001100000000 A300
59 0110000001100010 6062
5B 0000000101000100 0144
5D 0000000101000100 0144
5F 0000000101000100 0144

61 1010001100000000 A300
63 0110000001101100 606C

Isn't that interesting!

There is obvious pattern, it repeats and is static except one that contains current vertical and horizontal position but it isn't value from copper list because horizontal position seems to be actual $0144 write position! (+9 to copper horizointal wait value)

$0144 is register that was written to. (It changes to $0146 if copper writes to SPRxDATB)

Any ideas what $A300 means?

I am not really sure what this behavior means except that it must be some internal chipset bus value that gets copied to sprite output shift register.

Bitplanes were disabled in this (when I had single plane active, it did affect pattern at least in single horizontal position), border sprites enabled, only copper and sprite DMA active.

[ross]

.vposr

[Toni Wilen]

Thats it, it becomes A301 if current vpos >255. It did feel familiar value..

This means it is Alice that puts "something" (most likely result of some internal operation that was done in previous cycle) in upper 16 bits of sprite (bus is 32 bit wide so it does make sense) value when writing to SPRxDATx which is Lisa register and it does not have vertical counter.

[ross]

Unfortunately no use for these values, only usable for an accurate WinUAE glitches emulation.
Thanks Toni.

Ah, and thanks roondar for your last 'proof of concept'.

All these unexplored situations are always very very interesting.

[Toni Wilen]

I was too tired, obviously there is vpos accesses because main loop simply polls it.. So the logic is simple: last chipset data access gets copied to first 16 pixels of wide sprite.

$0144 is last copper access (first copper move cycle: load register number, second copper move cycle: write value to previously loaded register). It also explains why active bitplane makes difference in specific horizontal positions: if bitplane access is between two copper moves (copper uses only every other cycles): it becomes last cycle before copper does final write to $144. This is now emulated.

Remaining unknown: sometimes first two 16-pixel sprite "parts" contains duplicated chipset data.

EDIT: One correction in 32-pixel wide sprites: if FMODE has normal 32-bit sprite mode enabled (FMODE bit 2 set), both 16 pixel halves contain written data. Only if FMODE bit 3 is set (without bit 2 being set = sprite DMA mode works strangely) results in first 16 pixel having data bus contents and last 16 pixels contain written data.