English Amiga Board - Half pixel copper delay on A1200 hardware

English Amiga Board (https://eab.abime.net/index.php)

- Coders. Asm / Hardware (https://eab.abime.net/forumdisplay.php?f=112)

- - Half pixel copper delay on A1200 hardware (https://eab.abime.net/showthread.php?t=93380)

Half pixel copper delay on A1200 hardware

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)

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

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 :)

Quote:

Originally Posted by Toni Wilen (Post 1254184)

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).

Quote:

Originally Posted by ross (Post 1254223)

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

Quote:

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

I'll create a stand-alone repro.

Quote:

Originally Posted by Toni Wilen (Post 1254226)

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.

http://eab.abime.net/attachment.php?...1&d=1531584718

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!)

Code:

;# 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



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

Quote:

Originally Posted by FSizzle (Post 1254278)

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

Quote:

Originally Posted by ross (Post 1254282)

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.

Quote:

Originally Posted by FSizzle (Post 1254278)

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..)

Quote:

Originally Posted by Toni Wilen (Post 1254286)

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

Lazy man :p

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

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

:great

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

Quote:

Originally Posted by ross (Post 1254289)

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

:great

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

Uploaded HalfPixelTest.exe.

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

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 :rolleyes
(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

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.

Quote:

Originally Posted by ross (Post 1254305)

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..)

Quote:

Originally Posted by Toni Wilen (Post 1254342)

Good, so wasn't wine* :D

[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?

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)