which diwstart/stop/ddf for 336x248 lores display?

[jotd]

I'll never understand the logic of those start/stop registers... I'm always stuck with those values. Currently I have this

    move.w #0x2C51,diwstrt(a5)
    move.w #0x1cd1,diwstop(a5)
    move.w #0x0038,ddfstrt(a5)
    move.w #0x00D0,ddfstop(a5)
    move.w #0x0210,bplcon0(a5) | 8 bitplanes
    move.w #0x0024,bplcon2(a5)
    * AGA-compatible ECS default values
    move.w #0x0C00,bplcon3(a5)     | no AGA specificities, default ECS
    move.w #0,fmode(a5)            
    

    move.w #0,bplcon1(a5)    | foreground tiles
    move.w    #2,d0
    move.w d0,bpl1mod(a5)
    move.w d0,bpl2mod(a5)

works but two last columns are lost. I'd like to widen display by 16 pixels horizontal.

I usually add 16 there and there until I get the proper visuals but there it doesn't work. Overscan is way bigger than that so I know 336 pixels wide is doable!

[a/b]

320x256 non-AGA (or fetch=0): $2c81, $2cc1, $38, $d0 ($dff08e-94)
If you want to expand by 16px to the left: $2c71, $2cc1, $30, $d0.
If you want to expand by 16px to the right: $2c81, $2cd1, $38, $d8.
For 248 vertically, adjust $2c's (first one is start line, second one is end line) as you want, e.g. $30 and $28 to keep it centered.

[arcanist]

I've found this explanation useful for calculating the right values.

[ross]

The answer of a/b is fine and is the one that contains the canonical values, but there are possible alternatives and 'nuances' depending on the use you have to make of that screen..
Do you have to use all sprites? Do you have a screen that scrolls? Do you need to have a perfect overscan closure to the far right of the screen?

Because if you want a screen with an 8px column on the left and one on the right you can also use a 'hybrid' value for DDFSTRT and then correct with BPLCON1..

[Rock'n Roll]

for a 336x248 screen it's:
diwstart 2c71,diwstop 24c1 with ddfstrt 0x30, ddfstop 0xd0 (lores)

and I asked me, which point is the center of the visible amiga screen area?

vertical:
the vertical center point is: ($1a <--> $137) is: $a8 (168)
$137-$1a = $11d (285) so, the center is $11d/2 (285/2) = $8E (142) + $1a (26) => it's $a8 (168)

for screenheight 248 => 248/2 = 124 ($7c) --> $a8-$7C=$2c and $a8+$7c=$124

horizontal:
the horizontal center point is: ($5c <--> $1d3) is: $117 (279)
$1d3-$5c = $177 (375) so, the center is $177/2 (375/2) = $BB (187) + $5c (92) => it's $117 (279)

for screenwidth 336 => 336/2 = 168 ($a8) --> $117-$a8= $6F and $117+$a8=$1BF
(but this values are not optimal for ddfstrt, ddfstop)

[jotd]

I don't need sprites at all, no. Since I use AGA, being able to set fmode to 3 could be a bonus (even if I'm not going to use the blitter either, yeah). I'll soon unveil my project you'll understand why it is so

[ross]

Originally Posted by jotd

I don't need sprites at all, no. Since I use AGA, being able to set fmode to 3 could be a bonus (even if I'm not going to use the blitter either, yeah). I'll soon unveil my project you'll understand why it is so

Do you need scroll?

[a/b]

AGA/fetch won't be that easy because 336px = 42 bytes = not 32-bit aligned size. And you need that for all >0 fetch modes. And if you expand to 352px (=44 bytes), memory permitting, then you might as well use hw scroll by 8 to center the 336px wide screen (8+336+8), as Ross mentioned.

[jotd]

I don't need scroll. Just plain static screen.

FMODE could be a nice addition because I'll access chipmem with the CPU to write my 8x8 tiles in 256 colors. But if it's too complex for a very marginal gain, forget it.

[ross]

Originally Posted by jotd

I don't need scroll. Just plain static screen.

FMODE could be a nice addition because I'll access chipmem with the CPU to write my 8x8 tiles in 256 colors. But if it's too complex for a very marginal gain, forget it.

It's not that it's complex but you have to consider a modulo for each row of tiles (I'm not talking about hw modulo, but that you tile map will not be 42x30, but 'different'*).

Actually in FMODE=3 the x resolution need to be 384 to fit the 336 pixels.

*this means that your map in memory must always be 48x30
Of course you can also use 42x30, but remember to 'skip' 48px at the end of each line.

In any case you would have many more free slots for chip ram access so it might be worth it

EDIT: just noticed that you requested a y=248 screen.
I've calculated the 240==30 y-tiles based on your:

    move.w #0x2Cxx,diwstrt(a5)

    move.w #0x1Cxx,diwstop(a5)

that is a 240py screen.
But nothing changes, the problem only exists on the x, you will simply use an extra line of tiles on the y.

[ross]

These are the values I would use:
DIWSTRT=0x2e77
DIWSTOP=0x26c7
DDFSTRT=0x0030
DDFSTOP=0x00c0
FMODE=0x0003
BPLCON1=0xcc66
BPLMODx=0

The screen is centered 336x248.

Reasons for choices:
- the screen start is slightly higher than a 'calculated' exact centering, but it is more pleasant because it is usually too low for my taste, and we are naturally used to having the bottom area in black (but we are talking about a trifle anyway.. a couple of lines)
- the screen is slightly further to the left than the system centering, but it is more pleasant because it is usually too far to the right (another trifle)
- BPLCON1 adjusts the positioning with respect to all the values used
- the maximum x-value for DIWSTOP is used, otherwise you would have garbage displayed at far right if the extra 48px are not zeroed, or if -> (next point)
- you can use up to 7 sprites, which can always be used for overlay effects or whatever.

Of course, it's easy to correct if you don't like something.

The tile map must be positioned starting from (0,0), after the 42nd on x, you must skip 6 tiles (or 48 pixels)..

EDIT:
oh, I forgot, but this seemed obvious to me
In memory the screen is 384x248.

[jotd]

ok it seemed more complex than I thought. ATM I'm staying in FMODE=0

I've tried various suggestions but then modulo changed too... And I gave up FMODE=3 because of this alignment shit... We'll see later.

I could enlarge right, but lost a few pixels on the left (5 or 6)

    move.w #0x2C71,diwstrt(a5)
    move.w #0x1cf9,diwstop(a5)
    move.w #0x0030,ddfstrt(a5)
    move.w #0x00D0,ddfstop(a5)
	* AGA-compatible ECS default values
    move.w #0,fmode(a5)			
    move.w #0,bplcon1(a5)    | foreground tiles
	move.w	#0,d0
    move.w d0,bpl1mod(a5)
    move.w d0,bpl2mod(a5)

Now the secret project is not so secret...

[paraj]

If you wanted to keep project secret you should maybe also keep the github project private

Fetching and display window stuff can be a bit confusing, but another way to go about it is start from DDF as it puts a hard limit on where pixels can appear. Shifting will only delay from there.

Sticking to FMODE=0 (so OCS/ECS compatible). For a given even (OCS limit) DDFSTRT pixels will be available at DDFSTRT*2 + 17. So DDFSTRT=$30 => x part of DIWSTRT should be $30*2+17 => $71 (like you have). You get standard 320-width value ($81) from DDFSTRT=$38. (+17 is because fetching needs to happen one 16-pixel block before it's needed and there's an additional one lores pixel delay before it can be shown)

So next time you want to define a display, maybe start from a fixed DDFSTRT, calculate DDFSTOP=DDFSTRT+(screenwidth_round_up_to_near16pixels-16)/2 and then center later. (The -16 is because DDFSTOP is when then last block should be fetched).

Just another approach

[ross]

If you really want to stick to FMODE=0 (but then it is embarrassing slow..) you can adapt the values I've posted:

DIWSTRT=0x2e77
DIWSTOP=0x26c7
DDFSTRT=0x0030
DDFSTOP=0x00d0
BPLCON1=0x0066
FMODE=0x0000
BPLMODx=0

[jotd]

Originally Posted by paraj

If you wanted to keep project secret you should maybe also keep the github project private

I mean I didn't want to publicize the project until there's something showable as a video. It's really not far from that now thanks to everyone in that thread, special mention to ross.

DIWSTRT=0x2e77
DIWSTOP=0x26c7
DDFSTRT=0x0030
DDFSTOP=0x00d0
BPLCON1=0x0066
FMODE=0x0000
BPLMODx=0

I used 1ec7 for diwstop else it was too high. Now this is perfect. I'll have to switch to fmode = 3 at some point.

[ross]

Originally Posted by jotd

I used 1ec7 for diwstop else it was too high.

So it is really 240, not 248