hires, interlace, overscan - max screen size?

[Rock'n Roll]

I want open the maximum possible hires, interlace, overscan screen.
By test I get a possible size from normally: 720*567 but not with one display adjustment:

With a screensize: 640x567 (with: dc.w (Bpl1Mod/Bpl2Mod),80)

dc.w $8e,$1c61,$90,$38a1,$92,$2c,$94,$c4  ; works - display on the left edge
dc.w $8e,$1c89,$90,$38c9,$92,$40,$94,$d8  ; works - display on the right edge 

but it is not possible to shift the display by change on DIWSTRT/DIWSTOP
dc.w $8e,$1c8c,$90,$38dc,$92,$40,$94,$d8  ; no changes (shift 4px in the right direction)		
but with:
dc.w	$102,$33		; BplCon1 (works - shift to the complete edge of screen)

then the maximum size 704x567 and 720x567:
I tested:

dc.w $8e,$1c61,$90,$38c1,$92,$2c,$94,$d4  ; dc.w (Bpl1Mod/Bpl2Mod),88 	; works	(width: 704px)
dc.w $8e,$1c69,$90,$38c9,$92,$30,$94,$d8  ; dc.w (Bpl1Mod/Bpl2Mod),88 	; works (width: 704px)
dc.w $8e,$1c61,$90,$38c9,$92,$2c,$94,$d8  ; dc.w (Bpl1Mod/Bpl2Mod),90	; doesn't works (width: 720px)

but it is not possible to shift the display by change on DIWSTRT/DIWSTOP
dc.w $8e,$1c61,$90,$38c1,$92,$2c,$94,$d4  ; dc.w (Bpl1Mod/Bpl2Mod),88
to
dc.w $8e,$1c68,$90,$38c8,$92,$2c,$94,$d4  ; dc.w (Bpl1Mod/Bpl2Mod),88	; no changes (shift 7px in right direction)
but with:
dc.w	$102,$33		; BplCon1 (works - shift to the complete edge of screen)
				(but it seems to work not always correct with any value?)

So, the questions are:
1. Is a screenzize 720x567 possible?
2. And whats with the influence of the DIWSTRT/DIWSTOP values to shift the screen?

[ross]

Originally Posted by Rock'n Roll

...
So, the questions are:
1. Is a screenzize 720x576 possible?
2. And whats with the influence of the DIWSTRT/DIWSTOP values to shift the screen?

1) only from memory so take it with a grain of salt, maybe tonight I'll try it and give you the right parameters: 752x572 in OCS.
2) no influence.

[ross]

Ok, I've the values for OCS hi-res.

The x 'view' is 752 pixels, but you can't cover it completely with bitplanes DMA fetches, which can use at most 46 'sub-blocks' per line.
This means you can have 736 pixels; you can cover the rest with sprites, but obviously in OCS only with lo-res resolution.
The y 'view' is 572 lines; you can also possibly have 2 additional lines at the bottom of the frame, but which can only use COLOR00.

The minimum DIWSTRT is $1A5C, the maximum [EDIT: DDFSTOP] $38D4*.
The first pixel after the blank is with DDFSTRT=$28 and BPLCON1=$33.
Of course changing BPLCON1 you can 'move' the covered part and use some of the unused space at the extreme right (not completely, but in any case it is usually off-screen).

*this is a 'fake' value because Denise counter cannor reach this value.
$38C8 is already enough to enable an extreme overscan.

[Rock'n Roll]

It is not possible to use DIWSTRT/DIWSTOP to move the display in pixel steps to the next
DDF limit? So it "snaps" into place? I have always assumed that
it can be moved vertically and horizontally in pixelsteps.
But I can close the display this way from both sides. How does that work?

[ross]

Originally Posted by Rock'n Roll

It is not possible to use DIWSTRT/DIWSTOP to move the display in pixel steps to the next
DDF limit? So it "snaps" into place? I have always assumed that
it can be moved vertically and horizontally in pixelsteps.
But I can close the display this way from both sides. How does that work?

x and y DIWs are functionally different (although they appear to do similar things).
And absolutely not, you cannot horizontally move the display with DIWs (actually not even vertically, it is only a 'collateral' effect).

DIWs define the soft-blank area of the display, where COLOR00 is used to cover 'unwanted' parts.
Furthermore y-DIWs also defines what line the bitplanes DMA begins and ends.
That's why the side effect is to 'shift' the screen vertically.
The horizontal start on the line for the bitplanes DMA instead is defined by DDFSTRT.

EDIT:
I understand this may confuse you, but you need to understand that part of DIW, the y, is in Agnus, while the x is in Denise.
Denise is 'blind', it has absolutely no idea what line it is on, and needs STROBE signals to perform particular actions.
Agnus controls all the DMA activities therefore it has start registers both on the y (y-DIW) and on the x (DDFSTRT); accordingly it implicitly also defines the blank for the y coordinates.
Denise instead takes care of the video data output (bitplanes and sprites) and must therefore manage the (soft)blanking for the x (x-DIW) and the position for the data release (BPLCON1).

[ross]

oops, looking back and thinking about it better I have to slightly correct what I wrote in message #3
Indeed, by wasting another 2 sub-blocks you can cover an additional 8 pixels of the view (yes, a big waste, but that's just a proof of concept).

The hard-start for DDFSTRT can be even $18, so $20 is acceptable.
Setting to this value I add a block for the DMA fetch, adding 2 sub-block for the hi-res; this give a grand total of 48x16 pixel, i.e. 768.
Of course many are covered by blanking, but if I use BPLCON1=$77 (i.e. the maximum for hi-res) I can 'gain' pixels on the right.

Se the real visible maximum on x: 744 pixelx by bitplanes DMA

[Rock'n Roll]

Thanks ross, with the explanation of the mode of operation of the x/y-DIWs you reformed my sight here.

And also thanks for the explanation on the maximum size:
I made some tests again with following results:

1) dc.w $8e,$1c59,$90,$38c1,$92,$28,$94,$d4 ; 720x 45x16 (mod 90) works
2) dc.w $8e,$1c61,$90,$38c9,$92,$2c,$94,$d8 ; 720x 45x16 (mod 90) doesn't works
3) dc.w $8e,$1c59,$90,$38c5,$92,$28,$94,$d4 ; 728x 45,5x16 (mod 91) works
4) dc.w $8e,$1c59,$90,$38c9,$92,$28,$94,$d8 ; 736x 46x16 (mod 92) works
5) dc.w $8e,$1c51,$90,$38c5,$92,$24,$94,$d4 ; 744x 46,5x16 (mod 93) works
6) dc.w $8e,$1c51,$90,$38c9,$92,$24,$94,$d8 ; 752x 47x16 (mod 94) doesn't works
7) dc.w $8e,$1c49,$90,$38c1,$92,$20,$94,$d4 ; 752x 47x16 (mod 94) works

One questions remains: Why doesn't work no. 2) and 6) here?

[ross]

Originally Posted by Rock'n Roll

Thanks ross, with the explanation of the mode of operation of the x/y-DIWs you reformed my sight here.

And also thanks for the explanation on the maximum size:
I made some tests again with following results:

1) dc.w $8e,$1c59,$90,$38c1,$92,$28,$94,$d4 ; 720x 45x16 (mod 90) works
2) dc.w $8e,$1c61,$90,$38c9,$92,$2c,$94,$d8 ; 720x 45x16 (mod 90) doesn't works
3) dc.w $8e,$1c59,$90,$38c5,$92,$28,$94,$d4 ; 728x 45,5x16 (mod 91) works
4) dc.w $8e,$1c59,$90,$38c9,$92,$28,$94,$d8 ; 736x 46x16 (mod 92) works
5) dc.w $8e,$1c51,$90,$38c5,$92,$24,$94,$d4 ; 744x 46,5x16 (mod 93) works
6) dc.w $8e,$1c51,$90,$38c9,$92,$24,$94,$d8 ; 752x 47x16 (mod 94) doesn't works
7) dc.w $8e,$1c49,$90,$38c1,$92,$20,$94,$d4 ; 752x 47x16 (mod 94) works

One questions remains: Why doesn't work no. 2) and 6) here?

Everything here boils down to how bitplanes fetch works, which is not fully free.
In OCS you can have a defined block (which is 8 consecutive bus cycles) granularity.
In lo-res one block corresponds to the normal 6 maximum bitplanes per 16 pixels.
In hi-res you have 2 sub-blocks per block, for a total of 4 bitplanes per 16*2 pixels.
This means you can't have an odd number of sub-blocks in hi-res!

So regarding your cases:
1) this is actually a 46*16, with stop at $D8
2) this is actually a 46*16, with stop at $DC -> an overrun!, a real machine most likely crash here (bitplane DMA collides with memory refresh cycles)
3) same as 1)
4) good and right values
5) good values, but it can't be 744 or 46.5, this is a 736 (46*16)
6) same as 2) but a 48*16
7) this is actually a 48*16, with stop at $D8

How to distribute the contents of your image within the words in memory depends on how you will use BPLCON1 and how many pixels will be covered by the blank.

[pandy71]

Sorry for joining this interesting discussion but i see ITU 720x576 and 704x576 resolutions are discussed - there is problem with ITU resolutions as they are using different than Amiga pixelclock - ITU use 13.5MHz and PAL Amiga approx 14.18758Mhz so there is no direct pixel to pixel mapping (to cover 704 ITU pixels, Amiga need almost 740 pixels).

[ross]

Originally Posted by pandy71

Sorry for joining this interesting discussion but i see ITU 720x576 and 704x576 resolutions are discussed - there is problem with ITU resolutions as they are using different than Amiga pixelclock - ITU use 13.5MHz and PAL Amiga approx 14.18758Mhz so there is no direct pixel to pixel mapping (to cover 704 ITU pixels, Amiga need almost 740 pixels).

Right.
The 704 ITU resolution is basically fully covered by OCS chipset.
The 720 one is a little 'weak' in that case because it would require around 757 Amiga pixels, which in normal display are 752.
[ECS and AGA, in normal mode add a couple of pixels in hi-res, so nothing sensational]

If you also want precise indications on where the pixels are missing they are essentially some in the extreme right part of the video.
Instead on the left side the view could also be a little early and could even for one pixel overlap with the color burst signals*.
A 'problem' that in PAL has been here because of NTSC, given that some hardwired values are common, but the frequency in NTSC is a little higher and therefore the color burst would also end earlier.
Usually the color calibration occurs without problems, but in some devices with composite video it may also very slightly alter the line colors if extreme overscan is used (of course it is an exceptional case).

To be able to use the view completely, by using the horizontal blank to a minimum, it is only possible with the programmed modes (and they can be displayed in Overscan+ mode in WinUAE; there is also the Extreme mode in WinUAE which allows you to use part of the normal horizontal blank/burst to display video signal, some devices allow it).

But in any case we are talking about crumbs, parts of the signal which in any case and in any device of the 80s and 90s fell into the non-visible part.
And in fact using genlock and broadcast signals no one has ever complained about anything*

*EDIT
Actually the thing had been noticed, both by NewTek (which in a document talks about using a minimum DIW=$5D in PAL) and by Amiga HW support designers itself (which in WB Overscan never uses $5C as the minimum DIW, but $5D, at least from KS2.0+), even if Denise in fact could use that (lo-res) pixel.
I had never understood the reason for that document and those settings, until I found no other valid explanation from calculations using the timing of PAL signals, from ITU specifications and from various tests.
Obviously I could be wrong, but I'm looking for a valid alternative explanation

[Rock'n Roll]

that means, possible horizontal start and stop DDF-values for hires are:
$20,$24,$28,$2c,$30,$34,$38,$3c,$40,...,$D0,$D4,$D8 (but not $dc)
the stop must always be set to a multiple of 16 pixels
and if the ddfstop is not aligned, the next coming one is executed
$dc is an overrun value and can be the cause of problems on real machines

[pandy71]

Originally Posted by ross

The 720 one is a little 'weak' in that case because it would require around 757 Amiga pixels, which in normal display are 752.

ITU valid HW also can't display 720 pixels - this is limited by video line length - 720 is outcome of MPEG mod16 restriction - technically if your MPEG has 720 pixels size then video encoder is able to display approx 707 pixels max (some sources claim approx 710 even 711).
Normally video line is long 64uS, active video line carrying proper video line may be from 52uS long up to 52.4uS long (depends on blanking tolerance allowed by ITU standard) - so ITU valid HW (i.e. all broadcast and consumer devices) may display somewhere between 702 pixels up to 707.4 pixels. So realistically full active ITU compliant (i.e. ITU-R BT.470 standard) Amiga line length expressed in pixels should be between 737.75 and 743.43 to be comparable to ITU active video line.

video standards attached:

[ross]

Originally Posted by pandy71

ITU valid HW also can't display 720 pixels - ..

Yeah, I know all this
The 'issue' is that ITU is an 'attempt' to bring an analogue signal back to digital specifications and therefore 'rounds off' in many places.

The video window that the Amiga generates is the best compatible broadcast signal I have ever seen on any home machine of those years and many subsequent years.
All the various signals that are generated (pre/post-EQ, serrations, syncs, blanks) are superb.
But in any case they have limits and there are also devices that exceed the hardwired values it uses.
You often find tolerance specifications in manuals that exceed those of the Amiga.
This absolutely does not mean that Amiga is limited (on the contrary!), but that if you want to reach the maximum specifications in some cases you may not succeed.

Back to ITU the 'active' Amiga signal corresponds to 715.56 pixels, therefore more than sufficient for any real signal (not for the 'fake' 720).
The question is that in fact it is not perfectly 'centered' in respect to 'centered' ITU and therefore could have 'problems' at the 'edges'.

Consider that the 704/720 ITU 'pixels', as mentioned, are fixed frequency/digital defined and then must be transposed into analog, so there is a 'per device' conversion.
Amiga, on the other hand, outputs directly in analog PAL and drives the device, which thanks to large tolerances could accept more than '715 ITU pixels'.
So we are in an 'imprecise' environment and should support 'analog errors' and the Amiga does this very well, but can do it even slightly better with programmed modes.

Obviously we are talking about trifles, all 'problems' that arise only now where we have devices that allow us to 'go beyond' the original specifications and notice any little things (even a single shres pixel out of place)

EDIT: just to give you a concrete example.
Try to calculate where those 744 pixels generated by the Amiga bitplanes 'arrive' within the signal window and you will see that they do not reach the 52.x us extreme right edge in certain devices due to an early startup (yes, the first pixel emitted by Denise is in the 'blank' of the device).
Of course you cannot visually notice it, but is only a math or emulation situation

[pandy71]

Ok - checked Agnus datasheet and it is quite clear - whole line is 908 pixels long (active and inactive part - 227 CCK), line blanking area is 156 pixels long (5+17+17 CCK) this made active line 752 pixels long (188 CCK) - now your question is how much of these 752 pixels can be used by programmer to display video.

[ross]

Originally Posted by pandy71

Ok - checked Agnus datasheet and it is quite clear - whole line is 908 pixels long (active and inactive part - 227 CCK), line blanking area is 156 pixels long (5+17+17 CCK) this made active line 752 pixels long (188 CCK) - now your question is how much of these 752 pixels can be used by programmer to display video.

Totally right.
And also note that CCKs have some granularity and that DMA fetches also has some granularity (and rules).
You have to make compromises.

[pandy71]

Originally Posted by ross

Totally right.
And also note that CCKs have some granularity and that DMA fetches also has some granularity (and rules).
You have to make compromises.

Problem is that such information is not present in any documentation known to me. From DS it is quite clear - there is 188 CCK for active video. Some of them are not available, some partially available under particular restrictions.

[ross]

Originally Posted by pandy71

Problem is that such information is not present in any documentation known to me.

Simply because this documentation does not exist (at least that I know of).
The only possibility is to try (and that's what WinUAE is based on: test, test, test and.. test )

[pandy71]

Originally Posted by ross

Simply because this documentation does not exist (at least that I know of).
The only possibility is to try (and that's what WinUAE is based on: test, test, test and.. test )

But still this may be not enough so only Agnus logic schematics analysis may shed some light on this problem...

[ross]

Originally Posted by pandy71

But still this may be not enough so only Agnus logic schematics analysis may shed some light on this problem...

mmh, I'm a bit lost here. What problem are we talking about now?
If it is possible to 'cover' in hires all 752 pixels/52.xus theoretically available in OCS with bitplane data in DMA? No, it's not possible, I assure you*.
Instead in ECS, with programmed modes it is possible, but it is not trivial.

The main problem here is that we reach the absolute maximum available regarding the write cycle for BPL1DAT (in cycle 0 of the 'next' line) and the match for Denise counter and BPLCON1 ($1C7 AND $7).
I really don't know how to move the last output from the shifter forward.

EDIT* who knows, maybe with some absurd V(H)POSW trick.. but I don't want to think about it

[mc6809e]

Originally Posted by ross

EDIT* who knows, maybe with some absurd V(H)POSW trick.. but I don't want to think about it

Oh, c'mon. You know you want to.

I have been wondering what a flat creen might do if the VHPOS is walked back 16 pixels a few times per line. HSYNC frequency would be reduced but a few displays might be able to handle it as they tune themselves to the lower frequency.

I'd worry about old CRTs, though. Screwing with HSYNC frequency can possibly wreck a flyback transformer.