Half pixel copper delay on A1200 hardware

[FSizzle]

I have some code that uses the copper to set color00 every line, synchronized with the DIWSTRT/STOP (to get an extra color out of OCS amigas).

It works perfectly in WinUAE with OCS and AGA chipsets and also a real A500 (everything lines up perfectly), but on a real A1200 the color change is delayed by half a lores pixel.

I thought for the longest time there was something wrong with my code and (accidentally setting some AGA specific bits related to sub-pixel control, perhaps on my sprites or bitplanes) but I checked all of it and it seems correct. I finally thought to test another game that I know uses this per-line color00 change (Shadow of the Beast first level) and it also has this half pixel offset on my real A1200, but not in WinUAE (OCS or AGA) and not on my real A500.

Does anyone know:
- Is it possible this is still a code bug, that just happens to be the same in my code and Beast?
- Is there a known HW quirk that perhaps WinUAE does not emulate?

(PS - checked in WinUAE 3.5.0 and 4.0.0)

[Toni Wilen]

Attach simple example binary (that run when booted without startup-sequence), thanks.

[ross]

Finally a reference!

From old memories I seemed that I too had similar problems that drove me mad.
But they are old memories from 25 years ago, I just thought I was wrong.
I looked for a reference for a while but finding nothing so I had left off.

Also Lionheart use this technique and there's a code snippet that search for A1200 Lisa and change DIWSTOP..
http://eab.abime.net/showpost.php?p=...5&postcount=29 (leave out the other glitches that are in fact bugs)

I'm curious to know if this is real

[ross]

Originally Posted by Toni Wilen

Attach simple example binary (that run when booted without startup-sequence), thanks.

Toni, I can make a simple binary but if you run Lionheart first game level (or Shadow of the Beast) on A1200 you should notice the problem
(if it exists, as usual I can not confirm as I do not have a real machine).

[Toni Wilen]

Originally Posted by ross

Toni, I can make a simple binary but if you run Lionheart first game level (or Shadow of the Beast) on A1200 you should notice the problem
(if it exists, as usual I can not confirm as I do not have a real machine).

Simple test case is much better, games have too much happening at the same time.

[FSizzle]

Simple test case is much better, games have too much happening at the same time.

I'll create a stand-alone repro.

[ross]

Originally Posted by Toni Wilen

Simple test case is much better, games have too much happening at the same time.

Ok, here an exe to test.

Copper stripes is COLOR00, synced with DIWSTRT/STOP.
Red circle to better view if there is an half pixel mismatch.

[FSizzle]

I've uploaded a sample that reproduces the issue:
- a bootblock.s
- a bootable ADF image with that bootblock

I've also attached some images:
- Screenshot of WinUAE A1200 where everything lines up
- Screenshots of real A1200 running the test showing misalignment
- Screenshots of real A1200 running Shadow of the Beast showing misalignment

I hope we can get to the bottom of this!

(PS Sorry for the poor photos - I had a lot of trouble getting it to focus!)

;# BootBlock
;#-------------------------------------------------------------------------------
    dc.b	'D','O','S',0
    dc.l	0
    dc.l	880

;# Chipset
;#-------------------------------------------------------------------------------
REG_BASE    equ $dff000
COP1LCH     equ $080
DIWSTRT     equ $08e
DIWSTOP     equ $090
DDFSTRT     equ $092
DDFSTOP     equ $094
DMACON      equ $096
INTENA      equ $09a
INTREQ      equ $09c
BPL1PTH     equ $0e0
BPL1PTL     equ $0e2
BPLCON0     equ $100
BPLCON1     equ $102
BPL1MOD     equ $108
COLOR00     equ $180
COLOR01     equ $182

FRAMEBUFFER equ 256*1024

;# MAIN
;#-------------------------------------------------------------------------------
MAIN:
    lea     REG_BASE,a6                 ;# a6 always used as chipset base

    ;# Clear FRAMEBUFFER
    lea     FRAMEBUFFER,a0
    move.l  #(((320+16)*200)/32)-1,d0   ;# Fill enough for a single 320+16 x 200 bitplane
.fillLoop:
    move.l  #$0,(a0)+
    dbra    d0,.fillLoop    

    ;# Write one pixel on left and right of display
    lea     FRAMEBUFFER,a0
    move.l  #$80000000,(a0)             ;# Set pixel 0
    move.l  #$00000010,$24(a0)          ;# Set pixel 315

    ;# Activate CopperList
    lea     COPPERLIST(pc),a0
    move.l  a0,COP1LCH(a6)              ;# Set address of CopperList

    ;# Enable DMA
    move.w  #$8380,DMACON(a6)           ;# Master DMA, Bitplanes & Copper

    ;# Loop forever
LOOP:
    jmp     LOOP

COPPERLIST:
    ;# Activate frame buffer
    dc.w    DIWSTRT,$2C80
    dc.w    DIWSTOP,$F4BC               ;# 316 pixels wide
    dc.w    DDFSTRT,$0030               ;# Early fetch to support scrolling
    dc.w    DDFSTOP,$00D0
    dc.w    BPL1PTH,(FRAMEBUFFER>>16)   ;# Bitplane 0 high
    dc.w    BPL1PTL,(FRAMEBUFFER&$FFFF) ;# Bitplane 0 low
    dc.w    BPLCON0,(1<<12)             ;# Enable 1 bitplane
    dc.w    BPLCON1,$F                  ;# Scroll delay so we show first pixel
    dc.w    COLOR01,$A00                ;# Color01 red

    ;# Set COLOR00 in sync with DIWSTRT/DIWSTOP
    ;# First row
    dc.w    $2C<<8|$3F|$1,$FFFE
    dc.w    COLOR00,$AAA                ;# Color00 gray
    dc.w    $2C<<8|$DC|$1,$FFFE
    dc.w    COLOR00,$000                ;# Color00 black

    ;# Second row
    dc.w    ($2D)<<8|$3F|$1,$FFFE
    dc.w    COLOR00,$AAA                ;# Color00 gray
    dc.w    ($2D)<<8|$DC|$1,$FFFE
    dc.w    COLOR00,$000                ;# Color00 black

    dc.w    $FFFF,$FFFE                 ;# End

;#-------------------------------------------------------------------------------

[ross]

Originally Posted by FSizzle

I've also attached some images:
- Screenshot of WinUAE A1200 where everything lines up
- Screenshots of real A1200 running the test showing misalignment
- Screenshots of real A1200 running Shadow of the Beast showing misalignment

I hope we can get to the bottom of this!

Interesting!

I've uploaded an updated executable that shift plane2 with right mouse button press.
Can you test to see if the effect is visible?

EDIT: you need a PAL video mode

[Toni Wilen]

Originally Posted by ross

Interesting!

I've uploaded an updated executable that shift plane2 with right mouse button press.
Can you test to see if the effect is visible?

EDIT: you need a PAL video mode

It is visible but too much other copper stuff there to find the correct position in debugger. (I did say simple test..)

EDIT: include all AGA bplcon1 shift bits (shres resolution) in right mouse button press.

Originally Posted by FSizzle

I've uploaded a sample that reproduces the issue:
- a bootblock.s
- a bootable ADF image with that bootblock

Bootblock is too annoying to use, executable please. (Yes, I am really lazy..)

[ross]

Originally Posted by Toni Wilen

It is visible but too much other copper stuff there to find the correct position in debugger. (I did say simple test..)

Lazy man

Ok, I leave only some upper lines active (wait few minutes)

[ross]

Ok, attached a very stripped version
(works also on NTSC)



EDIT: ops, lost the EDIT from message #10 regarding shres shift, please wait an update...

[Toni Wilen]

Originally Posted by ross

Ok, attached a very stripped version
(works also on NTSC)

One more request: leave unshifted bitmap below or above the shifted part for reference.

[FSizzle]

Uploaded HalfPixelTest.exe.

[FSizzle]

Uploaded source for HalfPixelTest.exe I uploaded (it's the same as the bootblock.s, but with 2 changes):
- Set the FMODE to 0 in the copper list
- Remove the DOS header required for boot blocks

[ross]

For some reason that I do not understand now (too much wine?), quarter pixels scroll isn't working on WinUAE,
even if "superhires" on Host/Display/Resolution selected and AGA bits used
(so we need four right click for a visible shift..)

pf1 priority below pf2 and a fixed pattern for bitmap used.

EDIT: changed name because stoopid Windows10 Defender antivirus and cleaned some code

[FSizzle]

I've uploaded a new HalfPixelTest.exe. This simplifies the repro (exe is now 252 bytes ) and also eliminates some on-screen garbage when running from the WB or CLI.

@Toni. Let me know if this is helpful, or if changes would make it more useful.

[Toni Wilen]

Originally Posted by ross

For some reason that I do not understand now (too much wine?), quarter pixels scroll isn't working on WinUAE,
even if "superhires" on Host/Display/Resolution selected and AGA bits used
(so we need four right click for a visible shift..)

AGA hires/shres bits only work if both playfields have same scroll value. This is very old limit and supporting it is really complex (it can be also done easily but easy solution would also slow down everything..)

[ross]

Originally Posted by Toni Wilen

AGA hires/shres bits only work if both playfields have same scroll value. This is very old limit and supporting it is really complex (it can be also done easily but easy solution would also slow down everything..)

Good, so wasn't wine*

[this pf1!=pf2 AGA shift bits support could be a new feature for a later version of WinUAE, with option]

With my LUT approach was super simple to duplicate shift bits, so attached a version that work also on WinUAE.

Could other changes to the code be useful?

[Toni Wilen]

Does hires resolution also have exact same extra delay? (EDIT: I'll try to do some real hardware tests later today)

--

I probably explained it in some other thread but here is quick explanation:

This requires large rewrite, currently single Amiga lores/hires/shres pixel is single bit in whole display emulation path. Until finally output pixel color is decided (background, sprite or bitplane pixel) where single pixel becomes 1, 2 or 4 native horizontal pixels using optimized generated code. (every doubling mode has separate routine)

Everything is optimized for this behavior.

Sprites already support it because they are relatively simple and can't have weird side-effects. (like writing to BPLCON1 mid-scanline does)