Undocumented Amiga hardware stuff

[mr.spiv]

Originally Posted by Toni Wilen

Exactly. Seems only Cardamon/Cardamom's coder found and took advantage of this weird feature.



BLTDPT == BLTCPT after blit ends. (Demo Deformations won't work properly without this)

Heck.. never really understood how this worked back in day but I found it (or something similar) by accident and used it in this demo at least http://janeway.exotica.org.uk/release.php?id=4171
I never drew shorter lines or xorred any pixels

[Lekman]

Originally Posted by Toni Wilen

Sorry but there is not enough information. Obviously it is some corner case where nearly every DMA slot is in use but it is impossible to find the exact condition (which is the point of this thread, to document these features/bugs) without full code. You also mention sprites in comment but there is nothing in the code, also FMODE and BLTCON0 contents are missing.

I don't assume anything, full "buggy" code (binary is best, source isn't that good because different assembler may optimize it differently..) or nothing

Ok, here is the binary. No bug in winAUE, but on my original a1200.

(The two first downloads was with blitter nasty enabled (no bug) i upploaded new version 16.01.13. I now use 5 sprites and 3 dummy attacked sprites (so i can use the same colour as mask). The buggi version use 8 fullsize sprites, 3 attacked).

[Toni Wilen]

Originally Posted by Lekman

Ok, here is the binary. No bug in winAUE, but on my original a1200.

Thanks, I'll test it someday.

Originally Posted by mr.spiv

Heck.. never really understood how this worked back in day but I found it (or something similar) by accident and used it in this demo at least http://janeway.exotica.org.uk/release.php?id=4171
I never drew shorter lines or xorred any pixels

Nice. This really should have been documented because it made line drawing for filled vector objects so much simpler..

[Toni Wilen]

Not sure why I have missed this.. (Perhaps I am the the only one..) Probably because my usual test Amiga 500 has ECS Agnus.

DDFSTRT = 0x18 and OCS Agnus: All sprites are disabled. (ECS = sprite 0 is works normally, other sprites are disabled)

I checked this condition with logic analyzer and only first sprite word is fetched in this situation, second word fetch slot is not used.

It seems OCS Agnus expects idle cycle after both sprite fetches, when DDFSTRT = 0x18, second word is 1 cycle before first bitplane DMA slot.

[Photon]

Originally Posted by Toni Wilen

Nice. This really should have been documented because it made line drawing for filled vector objects so much simpler..

Still won't match up the slopes for you though, so it didn't solve the convex object shared edge glitch. (As demonstrated in Cardamon.)

Originally Posted by Toni Wilen

Not sure why I have missed this.. (Perhaps I am the the only one..) Probably because my usual test Amiga 500 has ECS Agnus.

DDFSTRT = 0x18 and OCS Agnus: All sprites are disabled. (ECS = sprite 0 is works normally, other sprites are disabled)

I checked this condition with logic analyzer and only first sprite word is fetched in this situation, second word fetch slot is not used.

It seems OCS Agnus expects idle cycle after both sprite fetches, when DDFSTRT = 0x18, second word is 1 cycle before first bitplane DMA slot.

I think I mentioned this is in my max overscan test? There should be a link somewhere in this thread. I think I didn't test if the scroll register affected it, and it shouldn't, but it's worth a test I guess.

[Toni Wilen]

Yes, BPLCON1 won't have any effect on DMA usage, it is Denise register.

I finally compared "blue" HRM and "black" HRM DMA time slot allocation page, differences are interesting:

Earlier revision says: "cycle $18 or earlier will wipe out all sprites" ... "if SPRITE0 is desired to function then the data fetches cannot begin any earlier than cycle $1c"

Later revision says: ..."This allows the user to wipe out most of the sprites if desired (by defining an extra-wide display)"..

ECS improvements have separate chapter but it does not mention fixed sprite 0 in max overscan (which is obviously a bug or some chip restriction because there is no DMA cycle conflict even if DDFSTRT=$18. It should have worked in OCS already.)

It looks like they didn't really want anyone to notice it

EDIT: I tested all DDFSTRT positions from $18 to $38 with OCS and ECS Agnus. OCS Agnus is always "off by one", DMA slot at DDFSTRT-1 is never used for sprite DMA if OCS (it is available for any other DMA channel or CPU).

[Photon]

So a Superfat Agnus should be enough to fix it? From memory it doesn't on a Rev 6A Superfat A500. Which should mean it was in two 1MB Agnus chip revisions at least? See Wikipedia. Would be cool to pin the change down to chip revision, that's the revision that's a true ECS Agnus to me anyway

[Toni Wilen]

Originally Posted by Photon

So a Superfat Agnus should be enough to fix it? From memory it doesn't on a Rev 6A Superfat A500. Which should mean it was in two 1MB Agnus chip revisions at least? See Wikipedia. Would be cool to pin the change down to chip revision, that's the revision that's a true ECS Agnus to me anyway

AFAIK all 1M (or 2M) chips are "fixed". 8372A and later ones. At least my A500 rev6 8372A works "correctly" and A1000 8367 and A500 8371 does not.

[Photon]

Confirmed. I think it was the 2nd bitplane of unattached 8th sprite missing or not at $30 I was thinking of.

[TheDarkCoder]

Hi Photon, I didn't know that bug you are mentioning. so when DDFSTRT = $30 the 2nd plane of the 8th sprite "flickers"? (only if sprite is not attached?)
I think I had seen this happening, but I thought it was a bug in my code
Only on certain Agnuses, I guess

[Toni Wilen]

Originally Posted by TheDarkCoder

Hi Photon, I didn't know that bug you are mentioning. so when DDFSTRT = $30 the 2nd plane of the 8th sprite "flickers"? (only if sprite is not attached?)
I think I had seen this happening, but I thought it was a bug in my code
Only on certain Agnuses, I guess

It is caused by same OCS Agnus "bug".

If DDFSTRT is large enough when sprite position information is fetched (POS&CTRL) but DDFSTRT becomes smaller when sprite is displayed, second "plane" of sprite stops getting updated (no DMA fetches) and last fetched data is reused in all following lines.

[Photon]

Yes, I don't remember it flickering.

[TheDarkCoder]

@Photon: so what do you mean, in your previous post with "8th sprite missing or not". I don't understand :-)

[Photon]

I only got the one bitplane showing, but that could be due to the first word in the second bitplane read being zero, and then repeated as Toni says. This raises the question how it has time to even read the first word, since it doesn't even get a DMA slot at any of the following lines. One guess is that it gets latched long beforehand, when the first bitplane DMA word is read at the top of the screen.

In other words, when DDFSTRT is $30, a slot is stolen from a sprite channel by the bitplane DMA starting ealier (more to the left), even though it shouldn't according to (some) documentation.

Originally Posted by Toni

EDIT: I tested all DDFSTRT positions from $18 to $38 with OCS and ECS Agnus. OCS Agnus is always "off by one", DMA slot at DDFSTRT-1 is never used for sprite DMA if OCS (it is available for any other DMA channel or CPU).

I think it could be the same bug causing both, but this doesn't explain why sprite 0 disappears completely at $18 but sprite 7 has 1 correct bitplane showing at $30. (Or maybe it does, I haven't drawn the positions on paper and compared to the cycle diagram in HRM. If it doesn't, it could be one more curious behavioral difference to investigate.)

[Toni Wilen]

Originally Posted by Photon

I think it could be the same bug causing both, but this doesn't explain why sprite 0 disappears completely at $18 but sprite 7 has 1 correct bitplane showing at $30. (Or maybe it does, I haven't drawn the positions on paper and compared to the cycle diagram in HRM. If it doesn't, it could be one more curious behavioral difference to investigate.)

I think it only depends what has happened previously. If both control words are fetched normally (bitplane disabled or ddfstrt large enough), sprite will be shown in correct position but second plane will contain whatever was last fetched to that register (SPRxDATB). It could be something from many, many frames ago, last line of sprite that was last correctly fetched.

I think it may even be possible to change the second plane pattern by manually writing to SPRxDATB using CPU.

[Photon]

Yes, of course that should work.

From a quick look in HRM you could hope that the bitplane DDFSTRT would steal less sprites in hires or if you're using less than 4 bitplanes in lores. Fetch order is _462_351, so you might even hope less than 2 bitplanes on will fix it. But when I got this I had 1 bitplane on, so that should crush the hope in both cases.

[Toni Wilen]

Originally Posted by Photon

From a quick look in HRM you could hope that the bitplane DDFSTRT would steal less sprites in hires or if you're using less than 4 bitplanes in lores. Fetch order is _462_351, so you might even hope less than 2 bitplanes on will fix it. But when I got this I had 1 bitplane on, so that should crush the hope in both cases.

Unfortunately "empty" bitplane slots still count, I tested it, number of planes makes no difference.

[mr.spiv]

Originally Posted by Photon

Still won't match up the slopes for you though, so it didn't solve the convex object shared edge glitch. (As demonstrated in Cardamon.)

I did not have edge glitch issue.. Must be then some other thing on my side

[Toni Wilen]

(Partially copied from http://eab.abime.net/showthread.php?t=71437)

How BPLCON1 really works:

When Agnus writes to Denise's BPL1DAT, all BPLxDAT registers are copied to internal Denise temp registers and flag is set. (separate flag for both odd and even planes)

When bitplane delay value (odd and even are separate) matches Denise's internal hpos counter ((hpos & mask) == delay value) and flag is set, internal temp register is copied to 16-bit output shift register and flag is reset.

Hpos comparison checks are continuous, internal copy happens immediately when comparison matches and if flag is set.

This explains all weird flickering/blanking side-effects if BPLCON1 values are modified "incorrectly" (comparison does not match before shift register empties too much) mid-scanline.

[JPQ]

In earlier this thread someone mentioned 7bit ocs mode how colours are defined in this mode? what i know there is only 32 colour registers.