Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too much sprite pixels per scanline #338

Open
GValiente opened this issue Nov 25, 2023 · 4 comments
Open

Too much sprite pixels per scanline #338

GValiente opened this issue Nov 25, 2023 · 4 comments
Assignees

Comments

@GValiente
Copy link

In the test ROM of this mGBA issue, if you press A button, NanoBoyAdvance 1.7.1 renders more sprite pixels than hardware.

In this case, VisualBoyAdvance seems to do the right thing:

nba_vs_vba

@fleroviux
Copy link
Member

It seems like there are some subtleties around the final cycle that can fetch sprite VRAM and the final cycle that can fetch sprite OAM. I have a tentative fix, but I think I will need to write some hardware test to figure out the right behavior for all cases.

@alyosha-tas
Copy link

I made a test for this case here: https://github.com/alyosha-tas/gba-tests/blob/master/ppu/Sprite_Last_VRAM_Access.gba

The result should be:

vram_test

The right edges of the black rectangles should align. The ones on top of the text run out of sprite rendering time as in the original test. The timing part of this test shows that the last vram access still happens as expected.

I think the interpretation here is that vram reading for sprites happens on the even cycles, while adding data to the internal sprite buffer happens on odd cycles. Sprite rendering shuts down on the odd cycles so the vram access still happens but the data isn't added to the buffer because the shut down happens.

It turns out the same thing happens when hblank free bit it set, which is demonstrated here: https://github.com/alyosha-tas/gba-tests/blob/master/ppu/Sprite_Last_VRAM_Access_Free.gba

@fleroviux
Copy link
Member

fleroviux commented Feb 14, 2024

@alyosha-tas Thanks for the additional test. I came to the same conclusion that the extra pixel had to be fetched but not output last time I looked at this, so your explanation mostly makes sense to me. But I would make an educated guess that pixel output/buffering can happen both on odd and even cycles for regular (non-affine) sprites. Probably the VRAM read is latched into a register and then processed over the next two cycle. To be able to output two pixels in a single cycle would add a lot of hardware overhead I think and it would be unlike anything I've seen on the GBA so far.

@alyosha-tas
Copy link

I guess that would need a separate test manually disabling sprite rendering on a VRAM access. I'll see about making additional tests for this case.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants