Skip to content

Fix two r.adf regressions: copper-chunky border COLOR00 + hi-res window-edge flush#154

Merged
LinuxJedi merged 2 commits into
mainfrom
fix/copper-chunky-border-color00-repaint
Jul 8, 2026
Merged

Fix two r.adf regressions: copper-chunky border COLOR00 + hi-res window-edge flush#154
LinuxJedi merged 2 commits into
mainfrom
fix/copper-chunky-border-color00-repaint

Conversation

@LinuxJedi

@LinuxJedi LinuxJedi commented Jul 7, 2026

Copy link
Copy Markdown
Owner

Fixes two rendering regressions in the "binary" demo (r.adf, KS1.3), both
in the Denise display path. Verified pixel-for-pixel against vAmiga.

1. Copper-chunky border follows per-pixel COLOR00 (0c85c8e)

The horizontal display-window flip-flop's closed intervals are repainted
with the border pixel after compositing. That repaint bounded each fill run
on the control (BPLCON/DDF) segments only and sampled COLOR00 once at the
run's start. When the copper rewrites COLOR00 across the border to draw a
colour bar (the copper-chunky technique behind the demo's red logo banner),
the write lands mid-run, so the whole border run was painted with the
frame-start COLOR00 and the colour change was dropped -- clipping the bar's
left edge and leaving stray colour fragments.

Denise applies COLOR00 per pixel in the border exactly as inside the
display window, so the repaint now ends each run at the next control or
palette (colour)
segment. Regression examples: the red banner rendered
short on the left and grew red noise lines as the copper's border COLOR00
writes were sampled at the wrong x.

2. Hi-res bitplane content flush at the 2H-196 window edge (1e476cb)

Standard hi-res ($81 DIWSTRT / $3C DDFSTRT) placed its first fetched
sample two framebuffer pixels inside the display window instead of flush
at the edge, so a 40-word row overran the window's closing edge and its
rightmost fetched pixel was masked as border. The 2H-196 comparator move
bumped both fetch references +1 "in lockstep"; lo-res stayed flush, but
hi-res has one framebuffer pixel per sample where lo-res has two, so the
same +1 shifted hi-res twice as far. Give hi-res the same 0x81 reference
as lo-res so both place sample 0 at the window edge.

Regression example: the AmigaDOS window's right vertical border reappears,
matching vAmiga (fb 62/700).

Validation

  • r.adf window + banner now match vAmiga pixel-for-pixel at both edges.
  • vAmigaTS (offset-normalised comparator, before vs after, ~562 tests):
    78 improved, 0 regressed -- Denise 39 (standard hi-res
    BPLCON0/modes reach 0.000%), Agnus/DDF 32 (late-DDF hi-res), BPLCON1 7,
    DIW unchanged.
  • KS1.3 / A1200 KS3.1 boot screens byte-identical.
  • Full unit suite (1348) + clippy + fmt green; three tests that encoded the
    old "2 hi-res px into the window" placement updated to the flush values,
    plus a new regression test for the closed-DIW border following COLOR00.

LinuxJedi added 2 commits July 7, 2026 21:39
The horizontal display-window flip-flop's closed intervals are repainted
with the border pixel after compositing. That repaint walked only the
control (BPLCON/DDF) segments to bound each fill run and sampled COLOR00
once at the run's start. When the copper rewrites COLOR00 across the
border to draw a colour bar -- the copper-chunky technique behind demo
logo banners -- the write lands mid-run, so the whole border run was
painted with the frame-start COLOR00 and the colour change was dropped,
clipping the bar's edge back to the previous control boundary.

Denise applies COLOR00 changes per pixel in the border exactly as it does
inside the display window, so end each repaint run at the next control OR
palette (colour) segment. The border now follows COLOR00 write-for-write.

Regression example: the "binary" demo (r.adf) red logo bar rendered
short on the left and grew stray colour fragments as the copper's border
COLOR00 writes were sampled at the wrong x.
Standard hi-res ($81 DIWSTRT / $3C DDFSTRT) put its first fetched sample
two framebuffer pixels inside the display window instead of flush at the
window edge, so a 40-word row overran the window's closing edge and its
rightmost fetched pixel was masked as border. On real hardware (and
vAmiga) the picture fills the window flush to both edges.

The 2H-196 comparator move set DIW_HSTART_FB0 to 0x62 and bumped both
fetch references +1 "in lockstep". Lo-res stayed flush, but hi-res has one
framebuffer pixel per sample where lo-res has two, so the same +1 bump
shifted hi-res twice as far and left it two pixels into the window. Give
hi-res the same 0x81 reference as lo-res so both place sample 0 at the
window edge; late-DDF hi-res (its border shows the pre-window samples)
follows the corrected reference too.

Regression example: the AmigaDOS window's right vertical border on KS1.3
(the "binary" demo, r.adf) reappears, matching vAmiga. vAmigaTS Denise,
Agnus/DDF and BPLCON1 buckets improve with no regressions; the standard
hi-res BPLCON0/modes references reach 0.000%.
@LinuxJedi LinuxJedi merged commit 9509676 into main Jul 8, 2026
8 checks passed
@LinuxJedi LinuxJedi deleted the fix/copper-chunky-border-color00-repaint branch July 8, 2026 05:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant