Sprite DMA problems - NESdev BBS

Sprite DMA problems
by visy on 2006-08-29 (#16653)

I'm having some trouble with sprites on a real NES. Again, emulators show them properly, but they are just aligned randomly and glitchy on the real NES.

On other parts of my program the sprite dma works fine, just this and one another scene I have go weird.

I'm using sprite dma at $0500-> and i've tried at least these fixes:

1. writing zero twice to $2003 before dma
2. disabling bg rendering altogether
3. not moving the sprites
4. removing a raster split from the screen I have on it

using $2003 and $2004 is glitchy too, but shows roughly half of the sprites (i wouldn't use it, but i tried it anyway)

Video capture from a PAL nes http://ameba.lpt.fi/~hataarto/bug.mp4

by Bregalad on 2006-08-29 (#16655)

1 - Did you make sure that you were proprely setting the right pattern table for sprites via $2000 ?
2 - Did you make sure you VBlank isn't too long, making sprite DMA during rendering ?

by visy on 2006-08-29 (#16657)

Yeah, the right pattern table is set (the x & y-coordinates are random too on real NES).

I'm not too sure about the VBlank thing, how could I check it? I only set the bytes for about 30 sprites, it shouldn't take very long, no fancy subroutines or calculations or anything.

by Bregalad on 2006-08-29 (#16658)

To check the VBlank thing you need to use the tracer in Nintendulator, however, your PC should be powerfull enough to not frezee at that time (my old PC was always doing that, and my new one still does sometimes).
Also, did you make sure you were completely reseting the sprite aera (write $f0 or above to it) before actually using it, and that you have no other variables stored in the same range ? Such problems should have appeared on emulators as well, but I'm asking for sure.

EDIT : I've checked your ROM, and I'm now sure the problem is that you're doing sprite DMA late in the frame instead doing this in VBlank. It does it on scanline ~14, wich is bad. You should FIRST do sprite DMA, then the rest.
And by looking what is in your pattern table, I can understand why you only put the version without BG online...

by Disch on 2006-08-29 (#16660)

My first thought is a hardware problem.

How are you getting this onto a PAL NES? Could it be this process is going wrong somewhere and corrupting the ROM? Have you tried putting a commercial ROM on whatever cart you're using and seeing if it works?

There's not a whole lot of things that could go wrong here, and all the problems listed so far would cause things to screw up in emulators as well as the actual system. I doubt very much that this is a software problem.

EDIT -- going to research Bregalad's new idea. I tested it in my emu which does look for $4014/$2004 writes during rendering and it was still working in PAL mode (but was broken in NTSC mode).

I'll see what I can find

by visy on 2006-08-29 (#16662)

I'm using fuzb's Funkyflashcart, with fuzb himself flashing it (he made the video). My program uses Mapper 3 (CNROM), which should be 100% supported. Can anybody test this on CopyNES or some other cart? This effect should work on a NTSC nes too.

by Bregalad on 2006-08-29 (#16663)

visy wrote:
This effect should work on a NTSC nes too.

It won't, you're doing your sprite DMA too late in the frame, instead of doing it in VBlank time.
The thing may work in PAL, but not in NTSC, as in Nintendulator.

by Disch on 2006-08-29 (#16664)

It most definatly will not work on NTSC because of what Bregalad mentioned -- but PAL mode should be working fine.

Either way -- you should push that DMA up sooner in the frame. DMA should be one of the very first things you do after an NMI. Try moving your $4014 write so that you do it right away rather than doing all that other crap first.

edit -- I almost suspect that video capture is actually NTSC and not PAL. Such unpredictable results are something you might expect from writing to OAM during rendering which you most definately are not doing when in PAL mode (but are doing on NTSC).

by visy on 2006-08-29 (#16665)

Okay, i'll try if it's the case.

I'm quite sure Fuzb uses PAL Nes (because the music runs on correct speed)

by Disch on 2006-08-29 (#16666)

visy wrote:
I'm quite sure Fuzb uses PAL Nes (because the music runs on correct speed)

Hrm... yeah I had my speakers off before so I didn't realize. Listening again to your mp4 and NTSC/PAL modes.... it does sound like PAL.

Very strange

by visy on 2006-08-29 (#16667)

Moving the DMA upwards the frame fixed it! Thanks for all the suggestions, developement on emulators is really frustrating at times

by Bregalad on 2006-08-29 (#16668)

Quote:
but PAL mode should be working fine.

No, because the DMA is set at the very end of the VBlank time. For that reason, I wasn't sure if DMA had been completed or not at the end of VBlank time, and I wasn't sure of what happens if DMA is only partially done in NMI and partially in the frame. For that reason, I said it *may* work, and looks like it effectivly was the problem, because I couldn't see any other problem (and now he's saying it's fixed).

by Disch on 2006-08-29 (#16673)

Bregalad wrote:
No, because the DMA is set at the very end of the VBlank time.

According to my logs, he was writing to $4014 no later than 35 scanlines into VBlank. Considering VBlank is 70 scanlines long on PAL, that leaves plenty of time for DMA to complete before VBlank is over.

The only time $4014 was written to outside of VBlank was the very first time it was written... but then, PPU rendering was disabled, so it was safe regardless.

I still see no reason whatsoever why his original linked ROM wouldn't work on a PAL NES.

visy: Could fuzb be using a famiclone rather than a PAL NES? Some famiclones trip an NMI 20 scanlines before VBlank ends rather than 70 in order to make them more compatible with NTSC games.

Quote:
(and now he's saying it's fixed).

I guess you're right -- this paticular problem is solved so it doesn't really matter.

But still... it just bugs me when something is going wrong when it shouldn't be... I prefer to know exactly what the problem is rather than get lucky by trying various things until one of them happened to work.

by Bregalad on 2006-08-29 (#16674)

Quote:
But still... it just bugs me when something is going wrong when it shouldn't be... I prefer to know exactly what the problem is rather than get lucky by trying various things until one of them happened to work.

I agree. I didn't log the CPU with Nintendulator, I just watched the scanline # with FCEUXD, wich doesn't tell the scanline index in VBlank (it just say 240 and then start again from 0).
I just sort of assumed that it was written to too late because of the long code before. That's also why I say it may work on PAL, and I didn't say it has no chance to work on PAL.

by visy on 2006-08-29 (#16675)

Disch wrote:
visy: Could fuzb be using a famiclone rather than a PAL NES? Some famiclones trip an NMI 20 scanlines before VBlank ends rather than 70 in order to make them more compatible with NTSC games.

No, he uses a stock PAL NES.