Interesting AGA bitplane overrun special case

[Toni Wilen]

(Not yet in undocumented features thread until more details are known)

I am not sure if this is new discovery but I haven't seen it used anywhere (not even sure if it is useful..). Originally here: http://eab.abime.net/showthread.php?t=83704

Lores AGA 64-bit bitplane fetchmode (FMODE=3) can overrun to next scanline without glitches and part of last fetched 64-bit block can be visible in left overscan. Smaller fetchmodes are completely hidden in horizontal blanking (and always conflicts with refresh slots), only FMODE=3 is wide enough.

I haven't done much testing (and it isn't fully emulated yet) but I guess it is possible it can be used to have full overscan with scrolling or to have overscan without losing most sprites.

It happens for example by setting FMODE=3, DDFSTRT=$28 (or $48 or $28+n*$20, with $48 effect is easier to see) and DDFSTOP=$e0. You should see bitplane data visible in left overscan, then gap and then normal bitplane after DDFSTRT position.

It happens because DDFSTOP is position that tells the chipset that there is one more bitplane "block" left to transfer. If fetchmode is 64-bit, one block is 32 dma slots long (up to 8 bitplanes + 24 idle cycles), next block starts from previous block + 32 cycles which in this case is cycle 5 or so in next scanline. There does not appear to be any protection for these kinds of "illegal" bitplane cycles.

Note that this can easily cause DMA conflicts, conflicts with refresh, disk, audio and possibly also sprite dma slots depending on DDFSTRT/STOP and number of planes. I don't know what exactly happens but at least refresh slot conflicts always cause graphics glitches. (I really need to find easy way to connect logic analyzer to my A1200 or A4000..)

[Toni Wilen]

I finally connected logic analyzer to my A1200's RGA bus (maybe more signals later if needed). It is confirmed, bitplane DMA slots really do appear at the beginning of scanline, just after last refresh slot. It is perfect fit

R-X-R-X-R-X-R-BPL8-BPL4-BPL6-BPL2-BPL7-BPL3-BPL5-BPL1

R = refresh
X = idle

Next test is to see what happens when conflicting DMA channel is also active (for example BPL1 should conflict with first audio channel, easier to test than disk DMA).

EDIT: Audio tested. If audio channel 0 is active, it will conflict with BPLDAT1 and cause graphics corruption. So if this trick can even be used for anything useful, first audio channel can't be be in DMA mode at the same time.

[mark_k]

With this bitplane overrun, does that increase the number of visible pixels on each scanline at all? Or is it still limited to 752?

I always wondered why various Amiga applications had an option for 768-pixel-wide overscan screens. Could some old (NTSC) chipset version have actually allowed 768 pixels to be displayed???

[Toni Wilen]

Originally Posted by mark_k

With this bitplane overrun, does that increase the number of visible pixels on each scanline at all? Or is it still limited to 752?

I always wondered why various Amiga applications had an option for 768-pixel-wide overscan screens. Could some old (NTSC) chipset version have actually allowed 768 pixels to be displayed???

It does not affect viewable area. Technically there is now even more than normally possible hidden pixels in far left but horizontal blanking hides them. "Nothing" is visible during horizontal blanking.

I think 768 was meant to be max possible pixels that DMA can fetch (with few of them hidden), at least when using "legal" ddfstrt/stop pair, but someone misunderstood.

[voxel]

Originally Posted by mark_k

I always wondered why various Amiga applications had an option for 768-pixel-wide overscan screens.

simple, PAL OCS Denise and OCS Agnus could do 768*580 (or 576)pixels wide maximum overscan, just like it was the case on pal television sets at that time.

when Commodore changed for the ECS chipset the maximum overscan shrinked to something like 724*536, I was told by them at that time that it was "cause only few video software used the 768 mode, and that was to economise some precious chipram/bandwith for new modes...", btw it was enough for a correct overscan on most monitors/TVs.

[Toni Wilen]

That sounds very wrong..

This is not about DMA but visibility of all 768 pixels. DMA has not changed at all, all chipset versions can fetch 768 hires pixels (or even more).

"Problem" is horizontal blanking, there simple isn't enough horizontal space to fit all pixels in space between two horizontal blanks. At least without adjustable pixel clock but Amiga only has 3 hardwired pixel clocks. (or using programmable modes but then it isn't really PAL or NTSC mode anymore..)

I still think 768 visible pixels is an error. Possible in theory, they all do exist inside the chipset, but not in real world.

[ross]

Hi Toni, I do not have access to a real machine to properly check, but
there is something wrong in 'overrun' emulation.

After making a simple copper list to test 'overrun' (I've probably an use for it..),
I could not see anything in active far left overscan.

DMA Debug give me a single slot occupation, in the last line only (313, PAL LOF).

After a couple of random copperlist test, I got it!
Overrun work only if there is Copper usage in the very same line.
(this explains why Moon Child AGA is working properly: it has copper trick in every visible video line).

Ciao!

[Toni Wilen]

Test binary required, as usual

[ross]

Originally Posted by Toni Wilen

Test binary required, as usual

Hi Toni, ignore my stupid code initilization (a fast rem of line..).

Copper wait on line $70 e $80, overrun trigger, else nothing.

Thanks!

Ross

[Toni Wilen]

Thanks. Fixed. It didn't switch to forced cycle-based line mode when overrun was detected.

[ross]

Thanks to You!
I'm pretty confident that is possible to make a full screen scroll without losing sprite, but I doubt without changing HSYNC position..

Ciao!