It is currently Tue Dec 11, 2018 11:03 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 33 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject:
PostPosted: Wed Jan 18, 2006 6:30 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
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:
 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.

Quote:
Code:
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...

Quote:
Code:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 18, 2006 8:00 pm 
Offline
User avatar

Joined: Tue Jan 17, 2006 10:39 am
Posts: 143
Location: North Carolina
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.....


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 18, 2006 8:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20853
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
lynxsolaris wrote:
Code:
 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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 18, 2006 9:08 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 19, 2006 10:41 am 
Offline
User avatar

Joined: Tue Jan 17, 2006 10:39 am
Posts: 143
Location: North Carolina
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:
... 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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 2:26 pm 
Offline
User avatar

Joined: Tue Jan 17, 2006 10:39 am
Posts: 143
Location: North Carolina
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 2:29 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1440
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 2:52 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
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?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 3:48 pm 
Offline
User avatar

Joined: Tue Jan 17, 2006 10:39 am
Posts: 143
Location: North Carolina
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:


 .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


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 4:58 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20853
Location: NE Indiana, USA (NTSC)
Quietust wrote:
Actually, the proper way is to write $2000 once and $2005 twice

This will work.

Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 5:31 pm 
Offline
User avatar

Joined: Tue Jan 17, 2006 10:39 am
Posts: 143
Location: North Carolina
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?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 5:59 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 7:46 pm 
Offline
User avatar

Joined: Tue Jan 17, 2006 10:39 am
Posts: 143
Location: North Carolina
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 ......


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 8:07 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 11011
Location: Rio de Janeiro - Brazil
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?

Quote:
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.


Quote:
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.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Jan 20, 2006 8:19 pm 
Offline
User avatar

Joined: Tue Jan 17, 2006 10:39 am
Posts: 143
Location: North Carolina
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?

Quote:
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.


Quote:
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?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 33 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: koitsu and 3 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