Graphical woes

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
User avatar
Sivak
Posts: 323
Joined: Tue Jul 17, 2007 9:04 am
Location: Somewhere

Graphical woes

Post by Sivak »

Alright. Things have been fine for a while, but in chat I have learned about sprites and conflicts. This has only come into play now that I've been trying to add NSF support to the game.

What basically happens is that some graphics don't show up and others are "moved over". I've even gotten an interesting attribute table being wrong.

So... I didn't get everything, so I figured I'd try doing a step-by-step look at this problem.

One thing that was mentioned involved how I'm clearing the memory. Basically, I'm doing this right now:

Code: Select all

RESET:
SEI          	; disable IRQs
CLD          	; disable decimal mode
LDX #$40
STX $4017    	; disable APU frame IRQ
LDX #$FF
TXS          	; Set up stack
INX          	; now X = 0
STX $2000    	; disable NMI
STX $2001    	; disable rendering
STX $4010    	; disable DMC IRQs
LDA #$00
STA $2003 	; set the low byte (00) of the RAM address

vblankwait1:       	; First wait for vblank to make sure PPU is ready
BIT $2002
BPL vblankwait1

clrmem:
LDA #$00
STA $0000, x
STA $0100, x
STA $0400, x
STA $0500, x
STA $0600, x
STA $0700, x
STA $0200, x  ;FLAGGED CODE
LDA #$FE
STA $0300, x
INX
BNE clrmem
   
vblankwait2:      ; Second wait for vblank, PPU is ready after this
BIT $2002
BPL vblankwait2
I recall hearing that $0200 should have all $FE's in there instead of $00. When I do that, the graphical things seem to go away, but the triangle wave starts playing low notes for no reason, leading me to believe something's wrong.

Another person had mentioned trying to put in code to skip the NMI routine a couple of times if a flag was set.

Anyway, is what I'm saying making sense and are there any easy answers?

Thanks and this'll be the last time I bug you this year! :)
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: Graphical woes

Post by Disch »

Sivak wrote: What basically happens is that some graphics don't show up and others are "moved over". I've even gotten an interesting attribute table being wrong.
This sounds like what might happen in an emu if you attempt to draw outside of VBlank. Make sure you aren't writing anything to $2007 once rendering has started.

On NMI, you should do everything drawing related first before calling other areas that aren't VBlank critical (like joypad reading). Your drawing code should also be as fast as you can make it to avoid running out of time.
STA $2003 ; set the low byte (00) of the RAM address
just felt like noting that the OAM address ($2003) is only 1 byte wide, so you're not setting just the "low byte", you're setting the whole address here.

Minor -- and it's not causing any problem in your code -- but a misnomer in some docs and I figured it's worth mentioning.
I recall hearing that $0200 should have all $FE's in there instead of $00.
Whoever suggested this probably said to do this because they were expecting you to use $02xx as your "shadow" OAM page (which you would later DMA to actual OAM via a write to $4014). Filling OAM with $00 would result in a cluster of unused sprites in the top left corner of the screen. Filling with a value between $F0-FF sets their Y coord so all unused sprites are offscreen (which is the preferred way to handle it)
When I do that, the graphical things seem to go away, but the triangle wave starts playing low notes for no reason, leading me to believe something's wrong.
If $0200 is your shadow OAM page, it shouldn't have any impact on anything else! Sounds like you're having the following problems:

1) you're putting variables in your $0200 page when you shouldn't be (if this is your OAM page, you can't have any other variables here!)

2) you're using unprepped RAM for your music and possibly drawing routines. Well not really since you're prepping it by clearing it -- but you still should be keeping an eye on possible variable contents. Maybe give your drawing and sound code a once over and look at variables and make sure you're setting all of them the way you want before you're relying on their contents.



and happy 2008!
albailey
Posts: 177
Joined: Thu Jul 13, 2006 3:15 pm

Re: Graphical woes

Post by albailey »

Sivak wrote:I recall hearing that $0200 should have all $FE's in there instead of $00. When I do that, the graphical things seem to go away, but the triangle wave starts playing low notes for no reason, leading me to believe something's wrong.
In your code you are not writing $FE to $0200, you are writing it to $0300.

If audio uses that memory and expects it to be zeroed, that might explain your audio weirdness.

Al
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

That is the shit about using NSF's that you have no idea how they work in your program... Each NSF uses a specific sound engine, and you never know when that is going to conflict with what you have already programmed, unless you really know the sound engine used.
User avatar
Sivak
Posts: 323
Joined: Tue Jul 17, 2007 9:04 am
Location: Somewhere

Post by Sivak »

Well, the NSF certainly does cause problems unforeseen... Although I don't know what I could do other than not using one. Is there any easy way around all this or is it probably going to be a lot of trouble to find out?

I've heard of ways of doing music without using NSF's, although they sound quite hard.
bunnyboy
Posts: 449
Joined: Thu Oct 27, 2005 1:44 pm
Location: CA
Contact:

Post by bunnyboy »

If you are using a well known nsf generator, you should be able to find out what memory ranges it is using (without just using a debugger). For example FamiTracker you can download the NSF driver source then see its ram usage in driver.s. Theres about 16 bytes of zero page and 100+ bytes of other ram variables defined for version 2. If you haven't made space for those, it will definitely be messing with your own stuff.
albailey
Posts: 177
Joined: Thu Jul 13, 2006 3:15 pm

Post by albailey »

Is there a link to the NSF sound engine you are using.

With that we can try and figure out what memory to avoid using. If its hosing $0200-$02FF you could have your sprites use a different memory page.

I've never used NSFs.

Al
User avatar
Sivak
Posts: 323
Joined: Tue Jul 17, 2007 9:04 am
Location: Somewhere

Post by Sivak »

I mentioned on another site that I'm using page $0400 for sprites instead of $0200 and this seems to be working. The real trick now is to get sound effects that I already have play correctly while music is playing.... They do play, but they sound all weird.
Post Reply