What is this AGA effect?

[NorthWay]

I was futzing around with display stuff and I got this odd result (see binary).
What is going on here? It kinda looks like an effect from differing number of slots per line? But it doesn't snowball so I can't see the logic of it.
Fixing the modulo to what it really should be brings it back to sanity.


Also doesn't match in WinUAE 3.6.1 to my 4000 (sorry, 4.x goes in a boot loop for me - I should make a support thread for that.)

[ross]

Actually even fixing the modulo (that cannot be -2, must be a multiple of 4 to not misalign everything when you have a 32bit fetch),
i've a properly display only when single 32bit CAS in enabled (FMODE=1, ignoring sprite's bits)!

With FMODE=2 i've the attached display. Why?
How do you see it in the real A4000? [DDFSTRT=30, DDFSTOP=C0, BPLxMOD=0, FMODE=2; all ok with FMODE=1].

[NorthWay]

This is what the exe looks like on my A4000 (see attachment)

[ross]

Originally Posted by NorthWay

This is what the exe looks like on my A4000 (see attachment)

wow, this is a work for Toni

[Toni Wilen]

Something strange is going on with modulo handling. I get similar (but not 100% same, I think bitplane fetching when FMODE=2 isn't exactly right after all) if modulo calculation adds extra 4 to modulo when bitplane pointer is not long aligned. This creates very similar looking "scanline" effect.

So bitplane pointer adder does incorrect calculation if input value(s?) are not integer divisible by fetch size? Modulo and bitplane fetch size are added at the same time so there probably is some FMODE related trick that causes conflicts in this situation.

EDIT: it would be interesting to see how image changes if bitplane FMODE=1 (not 2)

[Toni Wilen]

Could you do following tests:

- FMODE=1. How does the image change? (photo)
- DDFSTRT=0x30 (set also DDFSTOP=0xC2). This should make any difference except move the display horizontally but better confirm it too.
- Photos of following cases: Modulo=-4,0,2 and 4. (Yes, it will be total mess but there should be enough details to match it with emulator screens)

EDIT: I did some quick tests. "Unaligned" modulo and bitplane pointer does seem to work unexpectedly.

[Toni Wilen]

FMODE=1/2 module weirdness is now supported. (Note that test program does not set all palette entries so colors may be different depending on how you booted the program)

Logic seems to be: when bitplane pointer and modulo is added, bit 1 carry is ignored, for example 0x102 + 2 = 0x100. 0x102 + 0x12 = 0x110

FMODE=3 case is not yet updated.

[ross]

Thanks Toni, these improvements in the emulation of 'strange cases' are very useful.
Even though they actually use illegal or wrong modes, they make life simple for those who develop only on emulators but could find unexpected weirdness on real machines.
WinUAE is more and more accurate.

[Toni Wilen]

Exactly, bad/invalid/stupid/illegal/whatever situations must also work accurately.

FMODE=3 case is now correct. Similar weirdness, only difference is that bit 2 carry is ignored. Something like "if ((bplpt & (2 | 4)) + (modulo & (2 | 4)) >= 8) modulo-=8"

Only difference was modulo addition, BPL DMA fetch handling was already 100% correct.

[NorthWay]

Here are snaps from my A4000D. I think they should cover the questions:

[NorthWay]

Mods do whatever you need, this is the 9th attachment.

[Toni Wilen]

Thanks but I think I already solved it 100%. See previous posts.

[NorthWay]

I'll follow up here since my 4000 is in parts (again); if Toni or someone else has time to confirm what I was trying to test:

1. fmode 0/1/2/3 gives overscan in minimum 16/32/32/64 pixel steps and ddfstrt changes in minimum 8/16/16/32 value steps
2. Using copper to dynamically change fmode down from 3/2/1 to 2/1/0 happens when? Does it leave any artifacts?
3. Using copper to dynamically change fmode up from 0/1/2 to 1/2/3 happens when? Does it leave any artifacts? Can you break(confuse) the ddfstrt requirements?

Basically, I was trying to break how fmode 3 eats 7(?) sprites by starting each line with fmode 1/2 and changing to fmode 3 after the first fetch.
Can you confuse it to work, will it ignore the address bits to fetch something aligned with the fmode, will it change fetch aligned with the old or new fetchmode, will it sit waiting until the number of pixels put out matches its old or new fetch mode?
What happens when the address is 64-bit aligned but the ddfstrt isn't? (I.e. fmode 2; you do 1 32-bit fetch at a ddfstrt that is fmode 3 aligned or you do 2 32-bit fetches at a ddfstrt that is fmode 2 aligned and end up with an address that is good for fmode 3 but not a ddfstrt value. And then you change fmode to 3.)

[Toni Wilen]

1) DDFSTRT does not have any restrictions. Note that that BPLCON1 gets hidden offset added if DDFSTRT is "unaligned" (which is equal to size between DDFSTRT and previous "aligned" position) that can make it look like display start changed.

2-3) I haven't tested enough to be sure. Also most likely this isn't fully emulated (separation of Lisa and Alice FMODEs).