denise: correct out-of-range BPLCON0/BPLCON2 mode and priority decoding#117
Merged
Conversation
…layfield combo When BPLCON0 sets both the HAM and dual-playfield bits (an invalid combination no real software uses), Denise resolves the dual-playfield colour index and then runs it through the HAM logic: the HAM control code still comes from the raw plane 5/6 bits, but the value nibble (and the 'set' palette index) is the dual-playfield-resolved index rather than the raw plane bits. This mirrors vAmiga (translateDPF writes the resolved index into mBuffer, colorizeHAM reads the control from the raw bitplane bits) and the real-A500 photo. Copperline previously took the HAM-only path and ignored the dual-playfield bit for these pixels. The change is gated on both bits being set, so every valid mode renders byte-identically. vAmigaTS Denise/BPLCON0/modes4 10.9% -> 0.0%; invprio/modes3 improved.
…rent A dual-playfield field whose BPLCON2 priority code is programmed out of range (5-7) is drawn transparent: the winning field's pixels collapse to the background rather than revealing the field behind it. This mirrors vAmiga (zPF returns 0 for codes 5-7, masking that field's index to 0) and the real-A500 photo. Gated on the priority code being > 4, so valid dual-playfield content (codes 0-4) is byte-identical. Combined with the HAM+dual-playfield fix this resolves the vAmigaTS invprio cases, which set both an invalid priority and the invalid HAM+dual-playfield mode: invprio3 11.8% -> 2.4%, invprio1 6.4% -> 2.4%.
LinuxJedi
changed the title
…ority A single playfield whose BPLCON2 PF2 priority code is programmed out of range (5-7) keeps only bitplanes 5-6 wherever bitplane 5 is set -- eliminating the four low bitplanes -- and draws the pixel at background sprite priority. This mirrors vAmiga translateSPF (the quirk does not apply in HAM mode, which is handled separately). Gated on the priority code being > 4, so valid single-playfield content (codes 0-4) is byte-identical. vAmigaTS Denise/BPLCON0/invprio0 7.8% -> 3.3%.
LinuxJedi
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three closely-related fixes for how Denise decodes invalid BPLCON0 /
BPLCON2 programming (modes and priority codes that no real software uses).
Each is gated on its invalid condition, so every valid mode renders
byte-identically -- verified against
mainon phooey (OCS), TurboTomato(OCS), Roots (ECS), Roots (AGA) and Zool (AGA, dual playfield).
Fixes
Invalid HAM + dual-playfield combination. With both BPLCON0 bits set,
Denise resolves the dual-playfield colour index and then runs it through
HAM: the HAM control code comes from the raw plane 5/6 bits, the value
nibble from the resolved index. Copperline previously took the HAM-only
path and ignored the dual-playfield bit. (vAmiga
translateDPF+colorizeHAM.)Out-of-range dual-playfield priority. A dual-playfield field whose
BPLCON2 priority code is 5-7 is drawn transparent -- the winning field
collapses to the background instead of revealing the field behind.
(vAmiga
zPFreturns 0 for codes 5-7.)Out-of-range single-playfield priority. A single playfield with an
out-of-range PF2 priority code keeps only bitplanes 5-6 wherever bitplane
5 is set, eliminating the four low planes, at background sprite priority.
(vAmiga
translateSPF.)Accuracy (vAmigaTS
Denise/Registers, vs vAmiga 4.4 refs; no regressions)The dual-playfield priority handling was substantially wrong on
main(the whole
dualpfclass); it is now pixel-exact against vAmiga.Tests
cargo testgreen (1302 lib tests; adds three targeted tests);cargo clippyandcargo fmt --checkclean. Pure rendering change, noserialized-state change (STATE_VERSION unchanged).