It is currently Mon Dec 10, 2018 10:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: Sprite DMA problems
PostPosted: Tue Aug 29, 2006 9:15 am 
Offline
User avatar

Joined: Sat Aug 12, 2006 4:21 am
Posts: 28
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


Last edited by visy on Tue Aug 29, 2006 10:55 am, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 9:19 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7599
Location: Chexbres, VD, Switzerland
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 ?

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 9:23 am 
Offline
User avatar

Joined: Sat Aug 12, 2006 4:21 am
Posts: 28
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 9:28 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7599
Location: Chexbres, VD, Switzerland
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...

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 9:37 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 9:39 am 
Offline
User avatar

Joined: Sat Aug 12, 2006 4:21 am
Posts: 28
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 9:42 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7599
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 9:45 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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).


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 10:26 am 
Offline
User avatar

Joined: Sat Aug 12, 2006 4:21 am
Posts: 28
Okay, i'll try if it's the case.

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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 10:34 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 10:35 am 
Offline
User avatar

Joined: Sat Aug 12, 2006 4:21 am
Posts: 28
Moving the DMA upwards the frame fixed it! Thanks for all the suggestions, developement on emulators is really frustrating at times ;)


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 10:49 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7599
Location: Chexbres, VD, Switzerland
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).

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 11:28 am 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1849
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 11:43 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7599
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Tue Aug 29, 2006 11:55 am 
Offline
User avatar

Joined: Sat Aug 12, 2006 4:21 am
Posts: 28
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group