![]() |
![]() |
#1 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 214
|
hires, interlace, overscan - max screen size?
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) Code:
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) I tested: Code:
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?) 1. Is a screenzize 720x567 possible? 2. And whats with the influence of the DIWSTRT/DIWSTOP values to shift the screen? Last edited by Rock'n Roll; 16 March 2024 at 15:12. |
![]() |
![]() |
#2 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
Quote:
2) no influence. |
|
![]() |
![]() |
#3 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
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. Last edited by ross; 15 March 2024 at 18:54. |
![]() |
![]() |
#4 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 214
|
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? ![]() |
![]() |
![]() |
#5 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
Quote:
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). Last edited by ross; 15 March 2024 at 23:05. |
|
![]() |
![]() |
#6 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
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 ![]() |
![]() |
![]() |
#7 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 214
|
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? |
![]() |
![]() |
#8 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
Quote:
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. |
|
![]() |
![]() |
#9 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,917
|
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).
|
![]() |
![]() |
#10 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
Quote:
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 ![]() Last edited by ross; 16 March 2024 at 18:22. |
|
![]() |
![]() |
#11 |
German Translator
Join Date: Aug 2018
Location: Drübeck / Germany
Age: 50
Posts: 214
|
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 ![]() |
![]() |
![]() |
#12 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,917
|
Quote:
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: |
|
![]() |
![]() |
#13 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
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 ![]() Last edited by ross; 16 March 2024 at 21:15. |
![]() |
![]() |
#14 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,917
|
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.
|
![]() |
![]() |
#15 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
Quote:
And also note that CCKs have some granularity and that DMA fetches also has some granularity (and rules). You have to make compromises. |
|
![]() |
![]() |
#16 |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,917
|
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.
|
![]() |
![]() |
#17 |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
|
![]() |
![]() |
#18 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,917
|
Quote:
But still this may be not enough so only Agnus logic schematics analysis may shed some light on this problem... |
|
![]() |
![]() |
#19 | |
Defendit numerus
Join Date: Mar 2017
Location: Crossing the Rubicon
Age: 54
Posts: 4,529
|
Quote:
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 ![]() Last edited by ross; 16 March 2024 at 23:31. |
|
![]() |
![]() |
#20 | |
Registered User
Join Date: Jan 2012
Location: USA
Posts: 374
|
Quote:
![]() 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. |
|
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
RTG screen size - no overscan | Angus | Retrogaming General Discussion | 9 | 01 November 2023 22:48 |
Amiga games with Hires/Interlace options... | DDNI | Retrogaming General Discussion | 40 | 05 August 2019 10:00 |
PAL Hires, but with overscan of 1024 x 384 - possible? | mingle | support.WinUAE | 21 | 21 July 2010 13:11 |
ClassicWB Full for PAL Hires Interlace? | mingle | project.ClassicWB | 1 | 16 July 2010 15:54 |
WB overscan and screen size | Marcuz | support.Apps | 0 | 20 December 2006 16:40 |
|
|