sprite overscan

Hi all,

I have some invisible hires sprite in overscan mode (384*192), if i don't use overscan all my sprite are ok. if my DDFSTRT is inferior to $38 some sprite become invisible. If you have a solution for this problem it will be really appreciated.

Thanks you

[h0ffman]

I believe you loose a sprite in overscan. First or last one.

[Samurai_Crow]

It's true. The sprites' DMAs are fetched during the left border of the display. If you overscan too far left, the sprites will not be able to fetch their data.

It's a weird bug, each time i subtract 8 to DDFSTRT i lost 2 sprites. Ok no choice i will reduce my sprite, thanks for your answer

[Samurai_Crow]

It's not a bug. It is a well-documented behaviour. See http://amigadev.elowar.com/read/ADCD.../node0085.html for more details.

[pandy71]

btw is there any explanation for start display video difference between NTSC and PAL ie 21 vs 29 line?
Maybe CPU (or Copper in ECS) can start display earlier like wait for line 22 then write to VHPOSW 29

[Photon]

Originally Posted by pandy71

btw is there any explanation for start display video difference between NTSC and PAL ie 21 vs 29 line?
Maybe CPU (or Copper in ECS) can start display earlier like wait for line 22 then write to VHPOSW 29

The Amiga hardware was made to output PAL or NTSC signals to a monitor following those signal specs. Even today for flatscreen monitors, analog pixelcolors are pumped to the screen as if it was a CRT drawing scanlines in a phosphor layer, and the flatscreen monitor emulates a CRT's ray beam as the pixels come in. The timings for that is also following some standard signal spec, like VESA.

For an NTSC signal, the vertical retrace time is in specs, same for PAL. Any faster and the Amiga wouldn't be signal-compliant and maybe also incompatible with the monitors.

So unless you can speed up harvest or teleport me off this rock (translation from strangeland: mod your monitor to make the ray beam retrace faster and mod your Amiga to drive a shorter VBLANK pulse), you can't do this kind of vertical overscan. And on flatscreens it's of course useless, while a CRT can basically display any resolution, a TFT won't grow more pixels vertically if you feed it a shorter VBLANK...


There are also hard limits in Denise. The soft limits (vstart,vstop etc) vary with the chipset and the hard limits are unprogrammable. They are for the comparator and DMA timing/logic.

To maximize overscan you should find the max that is supported on all chipsets. The problem is that not all CRTs (forget TFTs for overscan!) have controls to squeeze all the overscan into the visible area, and also picture distortion can occur near the edges even if they do.

[pandy71]

Thnx Photon but video in PAL starting in second half line 23 (first half is occupied by WSS) so line 29 is bit late - this was my point - is there any explanation for this? Believe me - with time (yrs) many timings on video was relaxed, until some constraints are fulfilled then everything is OK. For me interesting is send WSS (ie first half of line 23). From my experiments (many yrs earlier) is clear that video timing - video lines number can be extended only by writing to VHPOSW lower than real line number - i only need to start display video earlier than in 29 line (NTSC 21 line is ideal - some VBI data can be send by Amiga but PAL is 29 so what makes difference?).

[Photon]

You can't change the DMA timings below the hard limits. If you modify the hardware to do so, some TVs or monitors will not have enough time to blank. If you maximize the overscan within the hard limits, everyone except people with flexible CRT monitors will see no more pixels than about 336x260.

"Why did they do that?" is like asking why they had x number of sprites or why HAM mode is done the way it is.

If you want to ask more pandy, ask in another thread I think... getting a little sidetracked this one

[pandy71]

its ok Photon, just curious - now i can't verify so just ask, it was interesting to know why such huge difference between NTSC and PAL.

[Photon]

Well, I just mean the guy with the info you want is the engineer who put in the hard limits when he made them for PAL Amigas He likely had reasons for them, and I suspect a big reason was to make it compatible with all PAL monitors/TVs at the time, combined with output timing possible with Denise.

If you want 5:4, square pixel overscan resolutions, two good ones are 336x269 (fills CRT TV) and 352x282 (fills a _good_ CRT monitor). Same resolutions could fill a 5:4 LCD monitor or flatscreen TV, but it depends on how smart the scaling electronics is. Alexh should know more about that, he's worked with such chips.

[pandy71]

Photon i only want to start display video bit earlier, nothing else - changing number of lines seems to be not a big problem (at least my experiments shows that vertical frequency changing with reducing/increasing VHPOSW) - i can add few lines later to keep timing constant.