search

c0pperdragon / C64-Video-Enhancement

Component video modification for the C64 8-bit computer
MIT License
256 stars 36 forks source link

sprite dma bug #63

Closed michielboland closed 3 years ago

michielboland commented 3 years ago

This may be a bit of an edge case, but on the VIC-II chip the turning on of sprite DMA and the turning on of the actual sprite are separate events (probably because of the 3-cycle BA thing.) One (DMA) occurs at x=332, the other (enabling of the sprite) at x=356. So there is a window of three cycles during which you can turn on DMA for a sprite without actually displaying it (either by quickly turning off the sprite enable bit or moving the sprite to a different Y-position.) The c64 component video board appears to behave differently here.

I have created a small program to illustrate the issue https://github.com/michielboland/c64stuff/blob/b61c8363094c62e46091a5256cd2446aec3794a9/asm/sprite_dma.s Screenshots from the same machine, one from the component output, and another from the s-video output. The component output displays 6 sprites, where there should have been only 3 visible.

sprite_dma_component sprite_dma_svideo

FWIW the latest VICE and Ultimate64 handle this properly.

c0pperdragon commented 3 years ago

Yes, I know of this incompatibility. It is also made apparent by some of the standard VIC-II test programs. Trouble is, I can not really fix this. My firmware does not internally keep track of the various counters needed to get this 100% correct and mainly relies on the sprite DMA happening. I just have not enough logic fabric left in the FPGA to implement this also. It is already a miracle that this much fits into a 2000 LUT device. I hope this issue is of not much practical relevance. You really have to go to very great lengths here just to not show some particular sprite.

michielboland commented 3 years ago

Fair enough, it's an extreme edge case anyway that is of no practical use.