questions to screen positions

Rock'n Roll · 04 February 2021, 19:28

The normal lowres screen (PAL) is 320x256
and a typical DIWSTRT-Position is horizontal: $81 (129) and vertical $2c (44)

Now there is a black border around the screen:
Now my questions:
1. Is the point in the upper left corner (0,0) or (1,1) or something else?
2. How far is the complete width? (border_left + 320 + border_right)?
3. The same for the high? (border_up + 256 + border_down)?
4. Where is in this system the center now?
5. Is it possible to put a lowres-screen in each corner?
(I know there is a horizontal limit $20)
6. Where are now the horizontal and vertical blanking areas?
For me the not visible area around the black border.

void setup() { // processing sketch
size(458, 312); // ???? stroke(255,0,0);
rect(0x81,0x2c,320,256); // lowres-screen DIWSTRT $2c81
}

ross · 04 February 2021, 20:16

1.
(0,1) Amiga 1000, (0,0) other machines

2.
$000~$05B hard blank (*)
$05c~$080 left soft blank
$081~$1c0 (320px)
$1c1~$1d3 right soft blank

grand total:
($1d4-$05c=376px) max overscan

(*) as the CCK are $e3 -> $1c6 'virtual lo-res pixels', from >=$1c6 you are already on the 'next line'
you can notice this using copper colors, and also using DIWSTOP(x)>=[($e4*2)mod256] that 'open the borders' (§)

(§) you may notice a small discrepancy here because in theory $1c6 should be the value [next line, 'open the border']
in fact Denise's internal counters range from 2 to 455 (they are advanced by 2) and therefore the last reachable position for DIWSTOP(x) is actually $c7.

3.
$000~$019 hard blank (on $019 you get first DMA sprite fetches)
$01a~$02b upper soft blank
$02c~$12b (256py)
$12c~$137 lower soft blank
$138 LOF last line (A1000 usable, other systems only COLOR00)

grand total:
($138-$01a=286px) max overscan

4.5.6. see before..

Rock'n Roll · 05 February 2021, 22:47

Hi ross,

thanks for your help.

Now I'm on this point.

// Processing-Sketch to illustrate the situation

void setup() {
size(468, 312); // horizontal: $0 to $1d3 = 468, vertical: $0 to $137 = 312
/*
$000~$05B hard blank (*)
$05c~$080 left soft blank // border_left
$081~$1c0 (320px)
$1c1~$1d3 right soft blank
grand total: ($1d4-$05c=376px) max overscan 468-92=376

$000~$019 hard blank (on $019 you get first DMA sprite fetches)
$01a~$02b upper soft blank
$02c~$12b (256py)
$12c~$137 lower soft blank
$138 LOF last line (A1000 usable, other systems only COLOR00)
grand total: ($138-$01a=286px) max overscan
*/

stroke(0,0,255); fill(10); rect(0x00,0x00,0x5b,0x138); // hard blank horizontal
stroke(0,0,255); fill(10); rect(0x00,0x00,0x1d3,0x19); // hard blank horizontal
stroke(0,255,0); fill(100); rect(0x5c,0x1a,375,286); // black border (soft blank)
stroke(255,0,0); fill(255); rect(0x81,0x2c,320,256); // lowres-screen DIWSTART $2c81
// grand total: ($1d4-$05c=376px) and ($138-$01a=286px) max overscan max overscan

//-------------------------------------------------------------------------------------------
// DIWSTRT($5c1a) DIWSTRT upper left corner
// DIWSTRT($5c37) DIWSTRT lower left corner y=$138-256 =$38 (56) 56+255=311 = $137
// DIWSTRT($931a) DIWSTRT upper right corner x=$1d4-320 =$94 (148) 148+320=468 = $1d4
// DIWSTRT($9337) DIWSTRT lower right corner
// stroke(255,0,0); fill(0,100,0); rect(0x5c,0x1a,320,256); // lowres-screen DIWSTART $1a5c
// stroke(255,0,0); fill(0,100,0); rect(0x5c,0x38,320,256); // lowres-screen DIWSTART $385c
stroke(255,0,0); fill(0,100,0); rect(0x94,0x1a,320,256); // lowres-screen DIWSTART $1a94
// stroke(255,0,0); fill(0,100,0); rect(0x94,0x38,320,256); // lowres-screen DIWSTART $1a94
//-------------------------------------------------------------------------------------------
DDF(); // DDF-Berechnung
}

// Copperlist
; 1. Standard
;dc.w $8E,$2c81 ; DiwStrt
;dc.w $90,$2cc1 ; DiwStop // $12c
;dc.w $92,$38 ; DdfStart
;dc.w $94,$d0 ; DdfStop
; 2. upper left
;dc.w $8E,$1a5c ; DiwStrt
;dc.w $90,$1a9c ; DiwStop $5c+320= $19c (420)
;dc.w $92,$26 ; DdfStart
;dc.w $94,$be ; DdfStop
; 3. lower left
;dc.w $8E,$385c ; DiwStrt
;dc.w $90,$389c ; DiwStop $5c+320= $19c (420)
;dc.w $92,$26 ; DdfStart
;dc.w $94,$be ; DdfStop
; 4. upper right
dc.w $8E,$1a94 ; DiwStrt
dc.w $90,$1ad4 ; DiwStop $94+320= $1d4 (468)
dc.w $92,$42 ; DdfStart
dc.w $94,$da ; DdfStop
; 5. lower right
dc.w $8E,$3894 ; DiwStrt
dc.w $90,$38d4 ; DiwStop $94+320= $1d4 (468)
dc.w $92,$42 ; DdfStart
dc.w $94,$da ; DdfStop

The result goes in the right direction. Maybe some pixel difference?

Now my new questions:
1. Where can I find the values in the literature?
2. What means overscan and why we dont use this? Because we lost sprite dma slots?
3. The normal lowres screen is 320x256 and the maximal lowres overscan screen is 376x286.
Can I fill the overscan screen with a big picture? I believe yes.
4. What means CCK?
5. $e3 is $1c6, because copper has 2px resolution so 2*$e3=$1c6 ?
6. 455/2 = 227.5 455=$1c7 (last reachable DIWSTOP(x) position) ??? show above 468
dc.w $90,$1ad4 ; DiwStop $94+320= $1d4 (468)
7. DIWSTOP(x)>=[($e4*2)mod256] = 456mod256 = 200 ??

ross · 06 February 2021, 01:30

I've corrected some values by you that are a bit off:

Code:

  size(454, 313); // horizontal: $e to $1d3 = 454, vertical:  $0 to $137(included) = 313
  (*) $1c6 to $1d4 are $0 to $d on next line
  /*  
  $000~$05B hard blank (*)
  $05c~$080 left soft blank // border_left
  $081~$1c0 (320px)
  $1c1~$1d3 right soft blank
  grand total: ($1d4-$05c=376px) max overscan 454-78=376 (*) 78=$5c-$e      
    
  $000~$019 hard blank (on $019 you get first DMA sprite fetches)
  $01a~$02b upper soft blank
  $02c~$12b (256py)
  $12c~$137 lower soft blank
  $138 LOF last line (A1000 usable, other systems only COLOR00)
  grand total: ($138-$01a=286px) max overscan  
  */

Quote:

The result goes in the right direction. Maybe some pixel difference?

Some DDF values you have written are a bit strange..

Quote:

Now my new questions:
1. Where can I find the values in the literature?
2. What means overscan and why we dont use this? Because we lost sprite dma slots?
3. The normal lowres screen is 320x256 and the maximal lowres overscan screen is 376x286.
Can I fill the overscan screen with a big picture? I believe yes.
4. What means CCK?
5. $e3 is $1c6, because copper has 2px resolution so 2*$e3=$1c6 ?
6. 455/2 = 227.5 455=$1c7 (last reachable DIWSTOP(x) position) ??? show above 468
dc.w $90,$1ad4 ; DiwStop $94+320= $1d4 (468)
7. DIWSTOP(x)>=[($e4*2)mod256] = 456mod256 = 200 ??

1. I've no idea, they are probably not available to the public but only in some internal technical document
2. Far edges outside the usual centered usable screen area, often partially covered on CRT monitors.
Yes, we lose sprites and also more DMA slots are required for bitplanes.
3. Yes.
5. Base clock in PAL Amiga architecture (3546895 Hz)
5. Not the copper, but how many lo-res pixel per CCK -> [$e3(CCK per line)x2(pixels)=454('virtual' pixels')]
6. Denise's counters cannot reach values >455, this implies open border and sprites x-coords unreachable, but pixels are visible (hw simply treats it 'on next line')
7. Yes

ross · 06 February 2021, 11:35

Probably a practical example will clarify you better than a sterile sequence of values.

What is probably more confusing is due to the fact that Agnus and Denise internal counters are differently based (and furthermore Denise only has horizontal counters and comparators).
In addition to the HRM it is highly recommended that you read also 'Undocumented Amiga hardware stuff' in this forum, it contains very useful information on how the chipset is supposed to actually work (it can be considered an addendum to HRM).

Let's move on to a practical example on a possible setting for a deep overscan (forgive me purists, I will simplify some things about what actually happens, I will use values related to lo-res pixel and I will ignore effects of BPLCON1 with 'strange' DDFSTRT values).

Normally when would you see the first on screen pixel relative to a defined DDFSTRT value (and using DIW metric)?
Using this formula: DDFSTRT*2 + fetch_width + delay (*) -> $38 * 2 + $10 + $1 = $81 (DIW)
(*) delay is only for bitplanes data, not for sprites data; this is, if I'm not wrong, another HRM undocumented effect, check for yourself

Maximum overscan 376 is not even divisible by 16 so use a close value: 368
If you use DDFSTRT = $28 and DDFSTOP = $D8 (§) you cover your screen from: $28 * 2 + $10 + $1 = $61 to ($d8 + $8 - $28) * 2 + $61 - 1 = $1d0 (inclusive).
[you may have noticed that I am over $1c7, so I am already forced to have no more control over border closure.. this has implications when using hardware scroll]
(§) on OCS there are maximum limits: DDFSTRT = $18 and DDFSTOP = $D8

This is very good because it covers a central part of my screen and leaves only 5 pixels in the far overscan (invisible) left ($5c, $5d, $5e, $5f, $60) and 3 pixels to the right ($1d1, $1d2, $1d3)

What if i want to use the remaining pixels too? (not recommended, it doesn't make much sense since they are usually not visible..)
I have to use an extra fetch and use the hardware scroll, since I'm free to fetch only from the left side, because from the right side I'm already at the hardware limit.

So: DDFSTRT = $20, DDFSTOP = $D8 and BPLCON1 >= $33.
At that point I will have some unused pixels in my fetch buffer.
Also I can't use too high values for the hardware shift because I would have another side effect that I let you discover

ross · 06 February 2021, 15:33

Ok, I've coded something to confirm everything I wrote above (I did it off the cuff and I wanted to actually confirm and try all situations).
Is as I wrote but I found something strange in the sprites emulation (in my opinion impossible) concerning the x-positions in the far right area of the screen (after $1c7).
Usually it is not a situation that happens, because sprites are used with closed video border and not with the x-position so far away.

I have no idea if it's an emulation shortcut, an error, an unexpected behavior or some strangeness existing in real hardware.
I talk about it with Toni, if anyone is interested I can also post something in this thread.

EDIT: fixed in today WinUAE

Photon · 06 February 2021, 17:01

Here is an article about maximum overscan, with some thoughts towards centering in different modes and for different display types. On OCS, it's not possible to turn on a border around the bitplanes. The background color continues to and across the right edge to the left edge of the next line, until it is set to a different color.

jotd · 26 February 2022, 16:47

My game emulates a portrait display, and I'd like it centered

Currently my values are

Code:

   dc.w  diwstrt,$3091            ;  DIWSTRT
   dc.w  diwstop,$2861            ;  DIWSTOP

   dc.w  ddfstrt,$0038            ;  DDFSTRT := 0x0038
   dc.w  ddfstop,$00d0            ;  DDFSTOP := 0x00d0

That starts on the left and ends on 3/4 of the screen (roughly). Is it possible to change some of those values to just center the screen horizontally?

I've naively tried to add values to ddfstart/stop but it trashed the screen (wrong modulo)

ross · 26 February 2022, 18:06

Quote:

Originally Posted by jotd

That starts on the left and ends on 3/4 of the screen (roughly). Is it possible to change some of those values to just center the screen horizontally?

uh.. this means a big amount of DMA bandwidth wasted!

Try this:
DDFSTRT=$50, DDFSTOP=$B8
BPL1MOD=$C, BPL2MOD=$22
DIWSTRT=$30C1, DIWSTOP=$2891

EDIT:
using these values you save 248*6*6=8928 DMA cycles per frame (from a previous total of 29760 for the bitplanes), not bad considering it's just using right values in the registers

jotd · 26 February 2022, 20:52

I'm going to try to figure that out anyway. Thanks. That worked with the scroll playfield as well after trying random value offsets for bplmod2

Now the screen is centered. For me those values have always been "magic" or mysterious. Never mind. That works.

ross · 26 February 2022, 21:10

Quote:

Originally Posted by jotd

thanks, but BPL2MOD changes when playing my game.

Yeah, I noticed that is dynamic. And used a 'right' value based on the other parameters (it would have been impossible to define without knowing how you structured and used the video data, for example the value of BPL1MOD is meant for an original fixed frame of 320px).
At least in the first level it works properly.

But you can calculate it based on the size of your video framework and how many fetches are done using the 'new' values

jotd · 26 February 2022, 21:22

OK, you got the context I see. Good!

I use BPL2MOD = BPL1MOD = $C for my menu, then change it to size_of_display+$C so that's coherent.

Finding the proper modulo isn't too hard by checking the result and computing the size of the slope increments of something that should be vertical

Yes, it's much nicer with a centered display.

ross · 26 February 2022, 21:51

Quote:

Originally Posted by jotd

I use BPL2MOD = BPL1MOD = $C for my menu, then change it to size_of_display+$C so that's coherent.

And now you know how I calculated the DMA cycles saved.

Considering that with the modulo you skips the read in each row of $C bytes (before no reading was skipped!), that you have 248 rows and that you have two playfields of three planes each (and that also in the second playfield you skip the same number of fetches), you will have

number_of_lines * ($C/2_word_skipped) * (3*2_planes)

= ...
Of course you can also calculate it differently and simply by considering the values of DDFxxxx, but they are two different ways of looking at the same thing.

Good work for Scramble!

jotd · 26 February 2022, 22:24

thanks! released the "final" version just now on itch.io. Well, some stuff can still improve but for now that's pretty good.

a/b · 26 February 2022, 22:34

A few weeks ago I was coding something similar. Without telling what it actually is (top secret as usual :P )... let say you want to scroll something from the left to the right without having to allocate 3x width, and if there is overscan involved and you don't want to extend your bitmaps with that, it can also compensate.
Basically, it dynamically calculates minimal required window and sets dma/mods/scroll to save dma bandwidth. I've filtered out my stuff, so this is a bare bones example (works in asm-one/pro):

edit: Correction, it doesn't calculate display window since I didn't need it (I was working with an extra wide screen).

Code:

;---------------T

****************************************************************

Width		EQU	320;+32
ExtWidth		EQU	32;-32		; overscan extension
Height		EQU	64
WidthB		EQU	Width/8
Depth		EQU	2
FullWidthB		EQU	Depth*WidthB	; interleaved

DMA_BASE		EQU	$30

****************************************************************

SYS_OFF	MACRO
	move.w	#$4000,($09a,a6)
	move.w	#$0020,($096,a6)	; no sprites
	ENDM

SYS_ON	MACRO
	move.l	(4).w,a0
	move.l	(156,a0),a0
	move.l	(38,a0),($080,a6)
	move.w	#$8020,($096,a6)
	move.w	#$c000,($09a,a6)
	ENDM

****************************************************************

	SECTION	TestCode,CODE

Code	lea	($dff000),a6
	SYS_OFF

	move.l	#CopperInit,($080,a6)
	move.w	d0,($088,a6)

	lea	(Bitmaps),a0
	moveq	#0,d0
	move.w	#(Bitmaps\.End-Bitmaps)/16-1,d1
.ClearBM	REPT	4
		move.l	d0,(a0)+
	ENDR
	dbf	d1,.ClearBM

	move.l	#Copper,($080,a6)

Main
.Sync	move.l	($004,a6),d0
	and.l	#$01ff00,d0
	cmp.l	#($60+Height)<<8,d0
	bne.b	.Sync
.WaitNext	move.l	($004,a6),d0
 	and.l	#$01ff00,d0
	cmp.l	#($60+Height)<<8,d0
	beq.b	.WaitNext

	movem.l	(Screens,pc),d0/d1
	exg	d0,d1
	movem.l	d0/d1,(Screens)

	move.w	(ScrollX,pc),d0
	moveq	#DMA_BASE-16/2,d2	; extra word for hw scroll
	move.w	#DMA_BASE+(Width-16)/2,d3
	moveq	#FullWidthB-WidthB-16/8,d4
	moveq	#$0f,d5
	IFGT	ExtWidth
		moveq	#ExtWidth/2,d6
	ENDIF
	and.w	d0,d5
	eor.w	d5,d0

	asr.w	#1,d0
	blt.b	.ShrinkRight
	IFGT	ExtWidth
		cmp.w	d6,d0
		blt.b	.ShrinkLeft
		sub.w	d6,d0		; shift display window to
		add.w	d6,d2		;  the right to compensate
		add.w	d6,d3		;  for overscan
	ENDIF
.ShrinkLeft	add.w	d0,d2
	asr.w	#2,d0
	add.w	d0,d4
	bra.b	.SetDisplay
.ShrinkRight	add.w	d0,d3
	asr.w	#2,d0
	sub.w	d0,d4
	ext.l	d0
	sub.l	d0,d1
.SetDisplay
	lea	(Copper+2),a0
	move.b	d2,(Copper\.DMA+1-Copper,a0)
	move.b	d3,(Copper\.DMA+5-Copper,a0)
	move.w	d4,(Copper\.Mods+0-Copper,a0)
	move.w	d4,(Copper\.Mods+4-Copper,a0)
	lea	(XToScroll,pc),a5
	move.b	(a5,d5.w),(Copper\.Scroll+1-Copper,a0)

	moveq	#Depth-1,d0
	moveq	#WidthB,d2
.SetPlanes	move.w	d1,(Copper\.Planes+4-Copper,a0)
	swap	d1
	move.w	d1,(Copper\.Planes+0-Copper,a0)
	swap	d1
	add.l	d2,d1
	addq.l	#8,a0
	dbf	d0,.SetPlanes

	move.l	(Screens\.Draw,pc),a0
	addq.l	#(Width-192)/(8*2),a0
	move.l	#$abababab,d0
	moveq	#Depth*Height-1,d7
.Draw	REPT	192/32
		move.l	d0,(a0)+
	ENDR
	lea	((Width-192)/8,a0),a0
	dbf	d7,.Draw

	move.w	(ScrollX,pc),d0
	addq.w	#1,d0
	cmp.w	#Width+ExtWidth,d0
	blt.b	.NoWrap
	neg.w	d0
.NoWrap	move.w	d0,(ScrollX)

.RMB	btst	#10-8,($016,a6)
	beq.b	.RMB
	btst	#6,($bfe001)
	bne.w	Main

Exit	SYS_ON
	rts

****************************************************************

	ALIGN	0,4
Screens
.Draw	DC.L	Bitmaps\.Buffer1
.Display	DC.L	Bitmaps\.Buffer2

ScrollX	DC.W	-(Width+ExtWidth)

XToScroll
.Ctr	SET	0
	REPT	16
		DC.B	$0011*.Ctr
.Ctr		SET	.Ctr+1
	ENDR

****************************************************************

	SECTION	TestChip,DATA_C

CopperInit	DC.W	$008e,$2c81,$0090,$2cc1
	DC.W	$0092,$0038,$0094,$00d0
	DC.W	$0100,$0200,$0102,$0000,$0104,$0000
	DC.W	$0106,$0c00,$010c,$0011,$01fc,$0000
	DC.W	$0180,$0000,$0182,$0973,$0184,$0751,$0186,$0531
	DC.W	$0144,0,$0146,0	; sprite0
	DC.L	$fffffffe

Copper
.DMA	DC.W	$0092,DMA_BASE,$0094,DMA_BASE+$08
.Mods	DC.W	$0108,FullWidthB-WidthB ; interleaved
	DC.W	$010a,FullWidthB-WidthB
.Scroll	DC.W	$0102,$0000
.Planes	DC.W	$00e0,0,$00e2,0,$00e4,0,$00e6,0
	DC.L	$6001fffe
	DC.W	$0180,$0323,$0100,Depth<<12+$0200
	DC.L	($60+Height)<<24+$01fffe
	DC.W	$0180,$0000,$0100,$0200
	DC.L	$fffffffe

****************************************************************

	SECTION	TestChipBSS,BSS_C

Bitmaps
.Buffer1	DS.B	Depth*WidthB*(Height+1)
.Buffer2	DS.B	Depth*WidthB*(Height+1)
.End

****************************************************************

Rock'n Roll · 28 February 2022, 18:01

In Lektion17f.s I have wrote a program to play with the screen values.
(This was my test program, to my question here.)
(right mouse button to switch)

Code:

diwtab:	
	dc.w $8e,$3091,$90,$2861,$92,$38,$94,$d0	; jotd	
	dc.w $8e,$30c1,$90,$2891,$92,$50,$94,$bb	; ross
diwtab_end:		
	dc.w $8e,$2c81,$90,$2cc1,$92,$38,$94,$d0	; 1. normale Bildschirmposition für (320x256)
	
BITPLANE:
	blk.b 10240,$FF

In Lektion17 is also an articel about this screen topic from my side. Hopefully not so much mistakes.
(asm-kurs5 on aminet) use machine translator...

28 February 2022, 18:01	#16
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 49 Posts: 183	In Lektion17f.s I have wrote a program to play with the screen values. (This was my test program, to my question here.) (right mouse button to switch) Code: diwtab: dc.w $8e,$3091,$90,$2861,$92,$38,$94,$d0 ; jotd dc.w $8e,$30c1,$90,$2891,$92,$50,$94,$bb ; ross diwtab_end: dc.w $8e,$2c81,$90,$2cc1,$92,$38,$94,$d0 ; 1. normale Bildschirmposition für (320x256) BITPLANE: blk.b 10240,$FF In Lektion17 is also an articel about this screen topic from my side. Hopefully not so much mistakes. (asm-kurs5 on aminet) use machine translator...

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Different applications in different positions on the screen	fxgogo	support.WinUAE	4	19 September 2020 20:00
on-screen display questions	honx	support.WinUAE	3	19 July 2020 20:29
Setting application screen positions?	Sinphaltimus	support.Other	2	22 January 2018 02:26
optimization, file reading and general screen questions in C	chocsplease	Coders. C/C++	37	28 May 2017 17:08
Full screen questions	CyckoNos	support.Amiga Forever	13	24 May 2011 14:34

04 February 2021, 19:28	#1
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 49 Posts: 183	questions to screen positions The normal lowres screen (PAL) is 320x256 and a typical DIWSTRT-Position is horizontal: $81 (129) and vertical $2c (44) Now there is a black border around the screen: Now my questions: 1. Is the point in the upper left corner (0,0) or (1,1) or something else? 2. How far is the complete width? (border_left + 320 + border_right)? 3. The same for the high? (border_up + 256 + border_down)? 4. Where is in this system the center now? 5. Is it possible to put a lowres-screen in each corner? (I know there is a horizontal limit $20) 6. Where are now the horizontal and vertical blanking areas? For me the not visible area around the black border. void setup() { // processing sketch size(458, 312); // ???? stroke(255,0,0); rect(0x81,0x2c,320,256); // lowres-screen DIWSTRT $2c81 }

04 February 2021, 20:16	#2
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	1. (0,1) Amiga 1000, (0,0) other machines 2. $000~$05B hard blank () $05c~$080 left soft blank $081~$1c0 (320px) $1c1~$1d3 right soft blank grand total: ($1d4-$05c=376px) max overscan () as the CCK are $e3 -> $1c6 'virtual lo-res pixels', from >=$1c6 you are already on the 'next line' you can notice this using copper colors, and also using DIWSTOP(x)>=[($e42)mod256] that 'open the borders' (§) (§) you may notice a small discrepancy here because in theory $1c6 should be the value [next line, 'open the border'] in fact Denise's internal counters range from 2 to 455 (they are advanced by 2) and therefore the last reachable position for DIWSTOP(x) is actually $c7. 3. $000~$019 hard blank (on $019 you get first DMA sprite fetches) $01a~$02b upper soft blank $02c~$12b (256py) $12c~$137 lower soft blank $138 LOF last line (A1000 usable, other systems only COLOR00) grand total: ($138-$01a=286px) max overscan 4.5.6. see before.. Last edited by ross; 06 February 2021 at 17:14. Reason: a bit of formatting...*

05 February 2021, 22:47	#3
Rock'n Roll German Translator Join Date: Aug 2018 Location: Drübeck / Germany Age: 49 Posts: 183	Hi ross, thanks for your help. Now I'm on this point. // Processing-Sketch to illustrate the situation void setup() { size(468, 312); // horizontal: $0 to $1d3 = 468, vertical: $0 to $137 = 312 /* $000~$05B hard blank () $05c~$080 left soft blank // border_left $081~$1c0 (320px) $1c1~$1d3 right soft blank grand total: ($1d4-$05c=376px) max overscan 468-92=376 $000~$019 hard blank (on $019 you get first DMA sprite fetches) $01a~$02b upper soft blank $02c~$12b (256py) $12c~$137 lower soft blank $138 LOF last line (A1000 usable, other systems only COLOR00) grand total: ($138-$01a=286px) max overscan / stroke(0,0,255); fill(10); rect(0x00,0x00,0x5b,0x138); // hard blank horizontal stroke(0,0,255); fill(10); rect(0x00,0x00,0x1d3,0x19); // hard blank horizontal stroke(0,255,0); fill(100); rect(0x5c,0x1a,375,286); // black border (soft blank) stroke(255,0,0); fill(255); rect(0x81,0x2c,320,256); // lowres-screen DIWSTART $2c81 // grand total: ($1d4-$05c=376px) and ($138-$01a=286px) max overscan max overscan //------------------------------------------------------------------------------------------- // DIWSTRT($5c1a) DIWSTRT upper left corner // DIWSTRT($5c37) DIWSTRT lower left corner y=$138-256 =$38 (56) 56+255=311 = $137 // DIWSTRT($931a) DIWSTRT upper right corner x=$1d4-320 =$94 (148) 148+320=468 = $1d4 // DIWSTRT($9337) DIWSTRT lower right corner // stroke(255,0,0); fill(0,100,0); rect(0x5c,0x1a,320,256); // lowres-screen DIWSTART $1a5c // stroke(255,0,0); fill(0,100,0); rect(0x5c,0x38,320,256); // lowres-screen DIWSTART $385c stroke(255,0,0); fill(0,100,0); rect(0x94,0x1a,320,256); // lowres-screen DIWSTART $1a94 // stroke(255,0,0); fill(0,100,0); rect(0x94,0x38,320,256); // lowres-screen DIWSTART $1a94 //------------------------------------------------------------------------------------------- DDF(); // DDF-Berechnung } // Copperlist ; 1. Standard ;dc.w $8E,$2c81 ; DiwStrt ;dc.w $90,$2cc1 ; DiwStop // $12c ;dc.w $92,$38 ; DdfStart ;dc.w $94,$d0 ; DdfStop ; 2. upper left ;dc.w $8E,$1a5c ; DiwStrt ;dc.w $90,$1a9c ; DiwStop $5c+320= $19c (420) ;dc.w $92,$26 ; DdfStart ;dc.w $94,$be ; DdfStop ; 3. lower left ;dc.w $8E,$385c ; DiwStrt ;dc.w $90,$389c ; DiwStop $5c+320= $19c (420) ;dc.w $92,$26 ; DdfStart ;dc.w $94,$be ; DdfStop ; 4. upper right dc.w $8E,$1a94 ; DiwStrt dc.w $90,$1ad4 ; DiwStop $94+320= $1d4 (468) dc.w $92,$42 ; DdfStart dc.w $94,$da ; DdfStop ; 5. lower right dc.w $8E,$3894 ; DiwStrt dc.w $90,$38d4 ; DiwStop $94+320= $1d4 (468) dc.w $92,$42 ; DdfStart dc.w $94,$da ; DdfStop The result goes in the right direction. Maybe some pixel difference? Now my new questions: 1. Where can I find the values in the literature? 2. What means overscan and why we dont use this? Because we lost sprite dma slots? 3. The normal lowres screen is 320x256 and the maximal lowres overscan screen is 376x286. Can I fill the overscan screen with a big picture? I believe yes. 4. What means CCK? 5. $e3 is $1c6, because copper has 2px resolution so 2$e3=$1c6 ? 6. 455/2 = 227.5 455=$1c7 (last reachable DIWSTOP(x) position) ??? show above 468 dc.w $90,$1ad4 ; DiwStop $94+320= $1d4 (468) 7. DIWSTOP(x)>=[($e42)mod256] = 456mod256 = 200 ??

06 February 2021, 11:35	#5
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Probably a practical example will clarify you better than a sterile sequence of values. What is probably more confusing is due to the fact that Agnus and Denise internal counters are differently based (and furthermore Denise only has horizontal counters and comparators). In addition to the HRM it is highly recommended that you read also 'Undocumented Amiga hardware stuff' in this forum, it contains very useful information on how the chipset is supposed to actually work (it can be considered an addendum to HRM). Let's move on to a practical example on a possible setting for a deep overscan (forgive me purists, I will simplify some things about what actually happens, I will use values related to lo-res pixel and I will ignore effects of BPLCON1 with 'strange' DDFSTRT values). Normally when would you see the first on screen pixel relative to a defined DDFSTRT value (and using DIW metric)? Using this formula: DDFSTRT2 + fetch_width + delay () -> $38 * 2 + $10 + $1 = $81 (DIW) () delay is only for bitplanes data, not for sprites data; this is, if I'm not wrong, another HRM undocumented effect, check for yourself Maximum overscan 376 is not even divisible by 16 so use a close value: 368 If you use DDFSTRT = $28 and DDFSTOP = $D8 (§) you cover your screen from: $28 2 + $10 + $1 = $61 to ($d8 + $8 - $28) * 2 + $61 - 1 = $1d0 (inclusive). [you may have noticed that I am over $1c7, so I am already forced to have no more control over border closure.. this has implications when using hardware scroll] (§) on OCS there are maximum limits: DDFSTRT = $18 and DDFSTOP = $D8 This is very good because it covers a central part of my screen and leaves only 5 pixels in the far overscan (invisible) left ($5c, $5d, $5e, $5f, $60) and 3 pixels to the right ($1d1, $1d2, $1d3) What if i want to use the remaining pixels too? (not recommended, it doesn't make much sense since they are usually not visible..) I have to use an extra fetch and use the hardware scroll, since I'm free to fetch only from the left side, because from the right side I'm already at the hardware limit. So: DDFSTRT = $20, DDFSTOP = $D8 and BPLCON1 >= $33. At that point I will have some unused pixels in my fetch buffer. Also I can't use too high values for the hardware shift because I would have another side effect that I let you discover

06 February 2021, 15:33	#6
ross Defendit numerus Join Date: Mar 2017 Location: Crossing the Rubicon Age: 53 Posts: 4,468	Ok, I've coded something to confirm everything I wrote above (I did it off the cuff and I wanted to actually confirm and try all situations). Is as I wrote but I found something strange in the sprites emulation (in my opinion impossible) concerning the x-positions in the far right area of the screen (after $1c7). Usually it is not a situation that happens, because sprites are used with closed video border and not with the x-position so far away. I have no idea if it's an emulation shortcut, an error, an unexpected behavior or some strangeness existing in real hardware. I talk about it with Toni, if anyone is interested I can also post something in this thread. EDIT: fixed in today WinUAE Last edited by ross; 06 February 2021 at 23:20.

06 February 2021, 17:01	#7
Photon Moderator Join Date: Nov 2004 Location: Eksjö / Sweden Posts: 5,602	Here is an article about maximum overscan, with some thoughts towards centering in different modes and for different display types. On OCS, it's not possible to turn on a border around the bitplanes. The background color continues to and across the right edge to the left edge of the next line, until it is set to a different color.

26 February 2022, 16:47	#8
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,161	My game emulates a portrait display, and I'd like it centered Currently my values are Code: dc.w diwstrt,$3091 ; DIWSTRT dc.w diwstop,$2861 ; DIWSTOP dc.w ddfstrt,$0038 ; DDFSTRT := 0x0038 dc.w ddfstop,$00d0 ; DDFSTOP := 0x00d0 That starts on the left and ends on 3/4 of the screen (roughly). Is it possible to change some of those values to just center the screen horizontally? I've naively tried to add values to ddfstart/stop but it trashed the screen (wrong modulo)

26 February 2022, 20:52	#10
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,161	I'm going to try to figure that out anyway. Thanks. That worked with the scroll playfield as well after trying random value offsets for bplmod2 Now the screen is centered. For me those values have always been "magic" or mysterious. Never mind. That works. Last edited by jotd; 26 February 2022 at 21:09.

26 February 2022, 21:22	#12
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,161	OK, you got the context I see. Good! I use BPL2MOD = BPL1MOD = $C for my menu, then change it to size_of_display+$C so that's coherent. Finding the proper modulo isn't too hard by checking the result and computing the size of the slope increments of something that should be vertical Yes, it's much nicer with a centered display.

26 February 2022, 22:24	#14
jotd This cat is no more Join Date: Dec 2004 Location: FRANCE Age: 52 Posts: 8,161	thanks! released the "final" version just now on itch.io. Well, some stuff can still improve but for now that's pretty good.

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)