question...

Are you new to 6502, NES, or even programming in general? Post any of your questions here. Remember - the only dumb question is the question that remains unasked.

Moderator: Moderators

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

Post by tokumaru »

I don't know anything about the assembler you're using, so I can't tell if you're doing anything wrong with it, but I'll try to help on NES/6502 specific stuff.
lynxsolaris wrote:

Code: Select all

 jsr wait_vblank
I've heard it is good practice to wait a while longer than 1 VBlank before doing PPU operations, so it can warm up or something. I'd suggest you call this routine like, 1 or 2 more times.

Code: Select all

palette:
 lda #$3F
 sta $2006
 lda #$00
 sta $2006
 ldx #$00
This seems fine, but... why LDX here? You haven't done anything with it afterwards...

Code: Select all

ppuinit:
 lda #%00000000 ; background at $0000
 sta $2000
 lda #%00001000 ; show backgrounds
 sta $2001
 jsr wait_vblank
 lda #$0
 sta $2005
 lda #$0
 sta $2005
 rts
I'd make the call to wait_vblank the first thing in this routine. Not that it REALLY matters in this case, 'cause you had the PPU off for a really short time (you wrote only 2 tiles), so the VBlank probably hasn't ended by now. But if you wrote more stuff, like a whole screen, we would be in the middle of rendering by now, and if you turned the screen on you'd actually see only part of it on the screen and it'd be probably pretty messed up.

It would be messed up for the rest of the frame, when you'd then write 0's to $2005. Well, just kick the VBlank waiting up and the rest is fine in this order.

One small note: there is no need to load A with #$0 twice, just load it once and write twice in a row. Not that there is an error here or anything, only loading once is faster. =)

I think that's it. I see no reason for it not to work. What do you see when you run this? Still the same 1 tile repeated all over?

You know what just crossed my mind? Some emulators cut the first and the last rows of the screen, wich means you'll not be able to see the stuff you wrote... try writing to the second or third row, preferably more to the middle... Try writing your tiles to address $2070 for example, instead of $2000.
User avatar
lynxsolaris
Posts: 143
Joined: Tue Jan 17, 2006 10:39 am
Location: North Carolina

Post by lynxsolaris »

tokumaru wrote: You know what just crossed my mind? Some emulators cut the first and the last rows of the screen, wich means you'll not be able to see the stuff you wrote... try writing to the second or third row, preferably more to the middle... Try writing your tiles to address $2070 for example, instead of $2000.
I've moved everything like you suggested. The LDX was from a previous
attempt and I forgot to remove it. Thanks for pointing that out.

After adding another wait_vblank and moving the tiles to $2070 (because
you were right ... the tiles @ $2000 were being cut off) I no longer have
a whole screen of tile 1 but the tiles I asked for (and blanking tile 00 and FF
thanks to Quietust)!

Thanks everyone for the better understanding of backgrounds ... now Im
on to scrolling.....
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

tokumaru wrote:
lynxsolaris wrote:

Code: Select all

 jsr wait_vblank
I've heard it is good practice to wait a while longer than 1 VBlank before doing PPU operations, so it can warm up or something. I'd suggest you call this routine like, 1 or 2 more times.
That or do what I do: jsr wait_vblank, clear most of CPU RAM (at $0000-$07FF), and then jsr wait_vblank again.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

tepples wrote:That or do what I do: jsr wait_vblank, clear most of CPU RAM (at $0000-$07FF), and then jsr wait_vblank again.
Yeah, this is probably a good idea. I just don't do that because I never assume any values. I only read stuff from places I've already written to, but not necessarily in huge "memory clearing" blocks. If you want to be safe, just clear the whole thing as tepples said.
User avatar
lynxsolaris
Posts: 143
Joined: Tue Jan 17, 2006 10:39 am
Location: North Carolina

Post by lynxsolaris »

tokumaru wrote:
tepples wrote:That or do what I do: jsr wait_vblank, clear most of CPU RAM (at $0000-$07FF), and then jsr wait_vblank again.
Yeah, this is probably a good idea. I just don't do that because I never assume any values. I only read stuff from places I've already written to, but not necessarily in huge "memory clearing" blocks. If you want to be safe, just clear the whole thing as tepples said.

Ok then I shall do that from now on. I just have one more question and
I should be well on my way. My beginning post I asked about adding
a second chr file (one for backgrounds and one for sprites) and Bregalad
was kind enough to answer. I've done the following:

Code: Select all

... other code removed to save space ..
palette:
 lda #$3F
 sta $2006	; SPRITE Palette
 lda #$10
 sta $2006

 lda #$0d
 sta $2007
 lda #$08
 sta $2007
 lda #$28
 sta $2007
 lda #$19
 sta $2007

 lda #$3F
 sta $2006	; BACKGROUND Palette
 lda #$00
 sta $2006

 lda #$0d
 sta $2007
 lda #$08
 sta $2007
 lda #$28
 sta $2007
 lda #$19
 sta $2007
 rts

... other code removed ...


ppuinit:
 lda #%10010000 ; <-- 2000.4 to add bg @ $1000
 sta $2000	
 lda #%00011000 ; <-- both sprite and bg bit on
 sta $2001	
 lda #$0
 sta $2005
 sta $2005
 rts

....other code removed ...

 .bank 1
 .org $fffa
 .dw nmi,main,int
 .bank 2
 .org 0
 .incbin "spr.chr"
 .incbin "bk.chr"  ; <--- added the background chr
All I can see is my sprite and not the background. Is there something
else I left out? It seems as though my second incbin (bk.chr) isn't going
to $1000 pattern table. I'll continue searching .. just thought someone
might have seen this right off. Keep in mind I am still using
nesasm.

Thanks
User avatar
lynxsolaris
Posts: 143
Joined: Tue Jan 17, 2006 10:39 am
Location: North Carolina

Post by lynxsolaris »

Ok I've yet to find the answer to what I'm doing I've picked up a few more documents
including Chris Covell's NES Technical/Emulation/Development FAQ document.
A section in there talked about "stable backgrounds" and somethings to try was clearing
$2006 at the end of NMI. Sorry to say it didn't work.... Can anyone give me a nudge?

thanks.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Post by Quietust »

lynxsolaris wrote:Ok I've yet to find the answer to what I'm doing I've picked up a few more documents
including Chris Covell's NES Technical/Emulation/Development FAQ document.
A section in there talked about "stable backgrounds" and somethings to try was clearing
$2006 at the end of NMI. Sorry to say it didn't work.... Can anyone give me a nudge?

thanks.
Actually, the proper way is to write $2000 once and $2005 twice - a double write to $2006 isn't very useful for setting the viewport at a specific location, since you're stuck (mostly) on tile boundaries and you have to do extra math to figure out the proper address to use.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

lynxsolaris, you are trying to get the second CHR file in place right? The code you posted seems fine, I don't think it has anything to do with the code, wich means no NES/6502 documents are going to help you. This seems like a assembler issue to. I never used NESASM, so I can't help you.

Are your CHR banks 4k in size each? What exactly is the problem you're having?
User avatar
lynxsolaris
Posts: 143
Joined: Tue Jan 17, 2006 10:39 am
Location: North Carolina

Post by lynxsolaris »

tokumaru wrote: Are your CHR banks 4k in size each? What exactly is the problem you're having?
um... yeah ... I'm about to go home and check my chr size. If they're bigger than 4k each
is that my issue? My problem exactly is that I can get sprites and background to show
at the same time. I can have either backgrounds showing at one time or the sprites. I've
set the appropriate values for $2000.3(0) and 2000.4 (1) and 2001.3/4 to 1. With these
values and

Code: Select all



 .bank 1
 .org $fffa
 .dw nmi,main,int
 .bank 2
 .org 0
 .incbin "spr.chr"
 .incbin "bk.chr" 

set I only see the sprites. Not the background. So at this point I'm assuming that you're
hinting that if the size isn't 4k a piece then that is my issue? Thanks.


EDIT: I did use yy-chr to create my chr files ... if that helps on the size question
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Quietust wrote:Actually, the proper way is to write $2000 once and $2005 twice
This will work.
a double write to $2006 isn't very useful for setting the viewport at a specific location, since you're stuck (mostly) on tile boundaries and you have to do extra math to figure out the proper address to use.
Unless you're using the top-left corner of a nametable like a lot of non-scrolling games use.
User avatar
lynxsolaris
Posts: 143
Joined: Tue Jan 17, 2006 10:39 am
Location: North Carolina

Post by lynxsolaris »

tepples wrote:
Quietust wrote:Actually, the proper way is to write $2000 once and $2005 twice
This will work.
Write when? at the end of NMI?
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

lynxsolaris wrote:If they're bigger than 4k each is that my issue?
I don't know, I really think it is an issue with the assembler. However, the worst thing that should be happening (in case you can't load the second CHR file) is that both of them (sprites and BG) were using the same pattern table (the same 256 tiles), and not one of them disappearing completly, wich is really strange.

Maybe the second CHR isn't beeing added correctly but the PPU tries to use it anyway, in wich case you'll only get blank stuff (in an emulator, anyway), but you have to ask the NESASM'ers around.
lynxsolaris wrote:Write when? at the end of NMI?
Whenever a frame is to be rendered, you do this before the frame starts. So, usually in the NMI, yes. The thing is that, for learning purposes and small stuff, people usually set up everything on start up and jump into an infinite loop, with NMI's disabled.

But in a real case scenario, you'd want to leave NMI's on, and set up the nametable to show ($2000) and the scroll values ($2005) at the end of it. You can rely on these writes to have your screen stable. $2006 can be used to scroll the screen, yes, but is only necessary when changing the scroll values in the middle of the screen for split-screen effects, and you shouldn't worry about it yet.
User avatar
lynxsolaris
Posts: 143
Joined: Tue Jan 17, 2006 10:39 am
Location: North Carolina

Post by lynxsolaris »

tepples, tokumaru:

I did what you guys said and that seemed to produce a better response.
I can see my sprite in front of a background ... however, its not the correct
background. It's reading my spr.chr (sprite) for the background. So
tiles 1 and 2 of the spr.chr are displayed ( not tiles 1 and 2 of bk.chr which
should be displayed). I downloaded nintendulator and when I select the
disassembly the pattern tables window only shows the contents of my
spr.chr and displays nothing from bk.chr. Does this sound like a compiler
issuse ( because I'm using nesasm) or just me probably doing something
dumb. Can post complete code if needed. Thanks for sticking in there with
me. I bet I never forget how to do backgrounds after this ......
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

lynxsolaris wrote:It's reading my spr.chr (sprite) for the background. So tiles 1 and 2 of the spr.chr are displayed ( not tiles 1 and 2 of bk.chr which should be displayed).
Now you probably set bit 3 and bit 4 of $2000 to the same value, having sprites and background use the same set of tiles, right?
I downloaded nintendulator and when I select the disassembly the pattern tables window only shows the contents of my spr.chr and displays nothing from bk.chr.
Then it is clear that bg.chr is not beeing included in the ROM.

Does this sound like a compiler issuse ( because I'm using nesasm) or just me probably doing something dumb.
Maybe you're doing something dumb that results in a compiler(assembler) issue! Just kidding... =)

Now seriously, maybe you just did not get the correct way of including CHR files in NASASM. I do it the old fashioned way: use the command prompt to join my files, using a command similar to "copy /b header + code + bg + sprites rom.nes".

If you can successifully add one CHR file, maybe you should join both and include it instead. Just do the copy thing in the command prompt: "copy /b spr.chr + bg.chr all.chr" and include all.chr instead. Maybe it will work then.
User avatar
lynxsolaris
Posts: 143
Joined: Tue Jan 17, 2006 10:39 am
Location: North Carolina

Post by lynxsolaris »

tokumaru wrote:
lynxsolaris wrote:It's reading my spr.chr (sprite) for the background. So tiles 1 and 2 of the spr.chr are displayed ( not tiles 1 and 2 of bk.chr which should be displayed).
Now you probably set bit 3 and bit 4 of $2000 to the same value, having sprites and background use the same set of tiles, right?
I downloaded nintendulator and when I select the disassembly the pattern tables window only shows the contents of my spr.chr and displays nothing from bk.chr.
Then it is clear that bg.chr is not beeing included in the ROM.

Does this sound like a compiler issuse ( because I'm using nesasm) or just me probably doing something dumb.
Maybe you're doing something dumb that results in a compiler(assembler) issue! Just kidding... =)

Now seriously, maybe you just did not get the correct way of including CHR files in NASASM. I do it the old fashioned way: use the command prompt to join my files, using a command similar to "copy /b header + code + bg + sprites rom.nes".

If you can successifully add one CHR file, maybe you should join both and include it instead. Just do the copy thing in the command prompt: "copy /b spr.chr + bg.chr all.chr" and include all.chr instead. Maybe it will work then.
I will try what you suggested. Just wondering .. what compiler do you
use?
Post Reply