question...

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic

question...
by lynxsolaris on 2006-01-17 (#8321)

Hello,

Im VERY new to nes development. I'm decently comfortable with getting
sprites on the screen and positioning them (haven't done any movement of
sprites yet). I'd like to try my hand at backgrounds .... thats where I need
some guidance. At this point I have my background images separate from
my sprites (in two different chr files). So I guess my starting question is if I
have .bank 2's .org at $0000 (for the sprites) then what would I need to do
to include the background as well? Would it be a new bank at $1000? Plus
I'm also assuming (which means I could be wrong) that I need to pass 1 to
bit 4 of $2000 (PPU Control Register 1) and 1 to bit 3 of $2001 (to show the
background). Any help is greatly appreciated.

by Bregalad on 2006-01-17 (#8322)

Quote:
I'm also assuming (which means I could be wrong) that I need to pass 1 to
bit 4 of $2000 (PPU Control Register 1) and 1 to bit 3 of $2001 (to show the
background). Any help is greatly appreciated.

That's pretty much correct. However, you'll have to first clear $2001.3 and $2001.4 to "turn screen off", that means that you can freely write your NameTable data and AttributeTable data to $2006/7 needed to have any background on screen. Once you're done, turn the screen on by setting bits 3 and 4 of $2001. If you need any other $2006/7 update while the screen is on, you have to do it during the VBlank time, right after an NMI. I don't guess you should try that at first, tough.

To include a second CHR file, just insert a second .incbin the second file after the first. I assume you're using NESASM, and I cannot say you that's bad due to the fact you're a newbie, but keep in mind that there are better assemblers out there.

EDIT : Oh yeah, once you have finished to draw your background, you HAVE to set the scrolling registers to get proper image on screen. To do that, wait a frame with $2002.7 or do that in your NMI routine. You should write twice to $2005 to get proper scrolling. If you don't do that (or if you just do that at reset), your scrolling will get altered by $2006 writes.

by lynxsolaris on 2006-01-17 (#8323)

Quote:
To include a second CHR file, just insert a second .incbin the second file after the first. I assume you're using NESASM, and I cannot say you that's bad due to the fact you're a newbie, but keep in mind that there are better assemblers out there.

Sorry. Yes I'm using nesasm. I've downloaded WLA-DX but figured I should
get a handle on nesasm before moving to something much bigger....

Quote:
EDIT : Oh yeah, once you have finished to draw your background, you HAVE to set the scrolling registers to get proper image on screen. To do that, wait a frame with $2002.7 or do that in your NMI routine. You should write twice to $2005 to get proper scrolling. If you don't do that (or if you just do that at reset), your scrolling will get altered by $2006 writes.

What I was messing with is a potential side scroller ... but was really just
trying to find my way to get a background just visible ... which brings me
to my next question...

I've been doing something like this for my sprites....
Code:

.bss

IMG.Y = $700
IMG.T = $701
IMG.S = $702
IMG.X = $703
... later...
clear the memory for sprites..

... later ...
lda #136
sta IMG.Y
sta IMG.x
lda #1
sta IMG.T
lda #0
sta IMG.S
... later (again) ...

lda #7
sta $4014 ; DMA 100x 7

Would I need to be doing my background tiles the same way? Is this even
the right way to really be doing the sprites? I've seen somethings on
name tables ... I think I understand what they are. (tile index #s in a file)
Just really not sure how to make them or use them. I downloaded the
chr2nam program but couldn't get it to work with my chr.

Also, is it better to use the sprite DMA or should I be using 2003/4?

Thanks so much for your help thus far.

by Bregalad on 2006-01-17 (#8324)

Quote:

Also, is it better to use the sprite DMA or should I be using 2003/4?

Sprite DMA is better, and you HAVE to do it in VBlank, so right after an NMI.

Quote:
Would I need to be doing my background tiles the same way? Is this even
the right way to really be doing the sprites? I've seen somethings on
name tables ... I think I understand what they are. (tile index #s in a file)
Just really not sure how to make them or use them. I downloaded the
chr2nam program but couldn't get it to work with my chr.

Background displaying works totally different than sprites. You'll have to fit your tile data in name tables and color data in attributes tables. (for your first try just put some data in one single nametable with screen off, wait for VBlank or for an NMI, and turn the screen on then write twice zero to $2005, be sure to write to $2000 to setup the good on-screen nametable and do sprite DMA).

by blargg on 2006-01-17 (#8325)

lynxsolaris wrote:
Sorry. Yes I'm using nesasm. I've downloaded WLA-DX but figured I should
get a handle on nesasm before moving to something much bigger....

That's the thing, nesasm's bank handling gets in the way as much as it helps, so other assemblers are easier to deal with, not harder.

by lynxsolaris on 2006-01-17 (#8326)

Quote:

Background displaying works totally different than sprites. You'll have to fit your tile data in name tables and color data in attributes tables. (for your first try just put some data in one single nametable with screen off, wait for VBlank or for an NMI, and turn the screen on then write twice zero to $2005, be sure to write to $2000 to setup the good on-screen nametable and do sprite DMA).

wow ... boy I really realize how much I still have to learn.... can you give me a little push on how to "fit your data in a name tables and color data into
attributes tables" .. I'm assuming it has something to do with $2006/7? Load
something into $2006 and then the actual data into $2007???? Or am I
WAY off. Thanks for the patience for a newbie.

by lynxsolaris on 2006-01-17 (#8327)

blargg wrote:
That's the thing, nesasm's bank handling gets in the way as much as it helps, so other assemblers are easier to deal with, not harder.

Oh I didn't know that. I was told that as someone just starting out that
nesasm would be the best for me.

by Bregalad on 2006-01-17 (#8328)

lynxsolaris wrote:
wow ... boy I really realize how much I still have to learn.... can you give me a little push on how to "fit your data in a name tables and color data into
attributes tables" .. I'm assuming it has something to do with $2006/7? Load
something into $2006 and then the actual data into $2007???? Or am I
WAY off. Thanks for the patience for a newbie.

I cannot help you much with the nametable and attribute table format, there is a lot of docs covering that. However, place your adress into $2006 (for example if you want to write at $2100 in PPU RAM to acess the nametable, write #$21, then #$00 to $2006), and then place a data or a string of data to $2007, the adress will automatically increment (be sure to keep $2000.4 clear, else it will increment by 32, usefull only to have column strings).

by tokumaru on 2006-01-17 (#8332)

Bregalad wrote:
(be sure to keep $2000.4 clear, else it will increment by 32, usefull only to have column strings).

lynxsolaris, if you are planning a side scroller, you'll definately be using this. I don't know if you got what Bregalad said, and before you get confused about the "auto increment" thing, I'd like to say a few things.

As bregalad said, you are right, just write the address where you want to draw the tiles to $2006 and then write the tiles to $2007. The auto increment makes it possible to write long runs of data by setting the address just once, when you begin. And you can choose how much to increment after every write, 1 or 32 bytes.

Increments of 1 are usefull when you draw from the left to the right, and increments of 32 are usefull when you draw from the top down. So, in a side scroller, you'll be using increments of 32, to constantly add new columns of graphics in the direction the player moves.

Well, it may be too soon to be thinking about the actual game, but... Well, play a little with the background and soon you'll begin scrolling stuf. I'd recommend you not to mess with the attribute table until you master the name table, ok? Just wanted to give you something to think about, so you can have an idea of how things work.

I had some trouble with the background at first because back when I programmed games for MS-DOS, I used to redraw the whole screen every frame. The NES is not fast enough for that, and you must draw only what's changed from one frame to the other.

by lynxsolaris on 2006-01-17 (#8335)

tokumaru wrote:
Well, it may be too soon to be thinking about the actual game, but... Well, play a little with the background and soon you'll begin scrolling stuf. I'd recommend you not to mess with the attribute table until you master the name table, ok? Just wanted to give you something to think about, so you can have an idea of how things work.

I definitely agree with you there. Right now Im just trying to get a background to read from a
chr and display the different tiles. I'd like to make a game some point but need to have a
better understanding of this beginning items first.

Thanks to both you and Bregalad for all your help so far. I started a new little test project
Here is the code I have thus far....
Code:

.inesprg 1
.ineschr 1
.inesmir 0
.inesmap 0

.code
.org $8000

main:
lda #%00001000
sta $2000
lda #%00001000
sta $2001

jsr wait_vblank
lda #$3F
sta $2006
lda #$00
sta $2006
ldx #$00

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

lda #$20
sta $2006
lda #$00
sta $2006

lda #$01
sta $2007
lda #$02
sta $2007
lda #$03
sta $2007
end:
jmp end

wait_vblank:
bit $2002
bpl wait_vblank
rts

nmi:
int:
rti

.bank 1
.org $FFFA
.dw nmi,main,int

.bank 2
.org $0000
.incbin "test.chr"

My writes to the color palette work fine ($3F00).
For some reason (and maybe this is what its suppose to do) it just displays the first tile tiled
over and over again. I thought if I wrote to $2006 (twice) with $2000 and wrote my tile
numbers to $2007 that it would show them? I believe Im missing something here ....

It does seem that if I just turn on the background bit (2001.3) that it automatically tiles the
first tile across the screen....

by Quietust on 2006-01-17 (#8336)

You need to reset the VRAM address after you're done writing to memory. To do this, write once to $2000 (to select which nametable to start rendering at) and then write twice to $2005 (to specify the horizontal and vertical scroll).

by lynxsolaris on 2006-01-18 (#8339)

Quietust wrote:
You need to reset the VRAM address after you're done writing to memory. To do this, write once to $2000 (to select which nametable to start rendering at) and then write twice to $2005 (to specify the horizontal and vertical scroll).

Thanks. So you have to set $2005 even if Im just trying to get an on screen background
without scrolling at this point?

by tokumaru on 2006-01-18 (#8341)

lynxsolaris wrote:
So you have to set $2005 even if Im just trying to get an on screen background without scrolling at this point?

Yes. The values you write to $2005 are the top left coordinates of the "camera" over the nametable. If you're not scrolling, just write 0 to $2005 twice and you'll have a full and static view of the name table you selected by writing to $2000.

Scrolling is just the effect produced by successive writes to $2005. If you write 0, 0, you'll see the nametable centered on the screen. Then, in the next frame you write 1, 0, wich means the camera moved a bit to the right. Then you write 2, 0, moving one more pixel to the right, and so on.

So, if you want to have a static screen you still have to write to $2005 so that the PPU knows where exactly to place the nametable on the screen.

by lynxsolaris on 2006-01-18 (#8347)

Thanks for you help so far. I spent my lunch break thinking
over the advice and knowledge you've given me so far. I think
I have a better understanding now but I'm not quite there yet.

If you don't mind ... heres some code ... please let me know anything you
see me doing wrong or if you think theres a "better" way I should be
doing it.

Code:
.inesprg 1
.ineschr 1
.inesmir 0
.inesmap 0

.code
.org $8000

main:
sei
cld
ldx #0
stx $2000
stx $2001

jsr wait_vblank
jsr palette
jsr nametable
jsr ppuinit
end:
jmp end

palette:
lda #$3F
sta $2006
lda #$00
sta $2006
ldx #$00

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

nametable:
lda #$20
sta $2006
lda #$00
sta $2006 ; name table @ $2000

lda #$00 ; index #1 in chr file?????
sta $2007
lda #$01 ; index # 2......
sta $2007
rts

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

wait_vblank:
bit $2002
bpl wait_vblank
rts

nmi:
int:
rti

.bank 1
.org $FFFA
.dw nmi,main,int

.bank 2
.org $0000
.incbin "bk.chr"

I'm still doing something wrong (obviously) because I still have blocks
(the first block image in my chr file) that tiles the entire screen. I'm
trying to get these blocks to do two or 3 rows near the bottom of the
screen. Any pointers? Thanks!

by Quietust on 2006-01-18 (#8348)

lynxsolaris wrote:
I still have blocks (the first block image in my chr file) that tiles the entire screen.

That's because most emulators initialize RAM to contain all zeros. Be careful, though - on the real hardware, RAM is initialized to mostly random values, so you need to initialize ALL memory you use - for the PPU, this means setting the VRAM address to $2000 and then writing $00/$FF 960 times to $2007 (followed by 64 bytes of $00) and making sure that tile 00/FF is "blank".

by tokumaru on 2006-01-18 (#8350)

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.

by lynxsolaris on 2006-01-18 (#8351)

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

by tepples on 2006-01-18 (#8354)

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.

by tokumaru on 2006-01-18 (#8356)

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.

by lynxsolaris on 2006-01-19 (#8364)

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

by lynxsolaris on 2006-01-20 (#8381)

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.

by Quietust on 2006-01-20 (#8382)

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.

by tokumaru on 2006-01-20 (#8384)

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?

by lynxsolaris on 2006-01-20 (#8385)

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

by tepples on 2006-01-20 (#8387)

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.

by lynxsolaris on 2006-01-20 (#8388)

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?

by tokumaru on 2006-01-20 (#8389)

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.

by lynxsolaris on 2006-01-20 (#8390)

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

by tokumaru on 2006-01-20 (#8391)

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.

by lynxsolaris on 2006-01-20 (#8392)

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?

by tokumaru on 2006-01-20 (#8394)

lynxsolaris wrote:
I will try what you suggested. Just wondering .. what compiler do you use?

Please, don't choose your tools based on my taste, I'm weird. But if you must know, I use Michal Kowalski's 6502 simulator (http://home.pacbell.net/michal_k/6502.html). It's great for larning and debugging. Since I was already so used with it, and since it can export binary data, I didn't bother looking for a more "traditional" compiler. I like that tool very much.

by Celius on 2006-01-20 (#8398)

By the way, you could just try and switch the incbined files. Instead of:

Code:
.incbin "spr.chr"
.incbin "bkg.chr"

You could try:

Code:
.incbin "bkg.chr"
.incbin "spr.chr"

And did I hear you say they're bigger than 4k each? Then that causes problems. You use YY-CHR? If you use the default file size, then you are using 8k for each one. I hope you know that both parts of the pattern table(sprites/background) have #$FF tiles each, so you can only have 256 tiles for backgrounds, and 256 for sprites. So with that in mind, open a new file in YY-CHR, take the tiles from your BKG data, and copy/paste them into the first half of the new file. Then take your sprites, and copy/paste them into the lower half of your new file, and save it as blah.chr. Then incbin that 1 file into your code instead of those two. If you really want to have your sprites and backgrounds in two 4k files instead of 1 8k, then go download a random hex editor, and start a new file, and put $1000 zeros, and save it as something.chr. Then open that file up with YY-CHR, then do your drawing, and save it as whatever.chr, and you'll have a 4k file. That's what I do when I want a specific .chr size...

EDIT: I read your post a little more, and I wanted to explain something. Since you are using 8k CHR files, you have 256 tiles of either bkg or sprites, and nothing for the other 256 tiles below that. So you can have 8k of data in the pattern tables at a time. When you incbin 2 8k chunks of data into the pattern table, it just incbins one and shuts the other one out. So put your two files into one. Take the data from the sprite one, and copy/paste it into the lower half of your bkg one, and save it. Then they'll both show up.

by lynxsolaris on 2006-01-21 (#8408)

Celius wrote:

EDIT: I read your post a little more, and I wanted to explain something. Since you are using 8k CHR files, you have 256 tiles of either bkg or sprites, and nothing for the other 256 tiles below that. So you can have 8k of data in the pattern tables at a time. When you incbin 2 8k chunks of data into the pattern table, it just incbins one and shuts the other one out. So put your two files into one. Take the data from the sprite one, and copy/paste it into the lower half of your bkg one, and save it. Then they'll both show up.

You're right on. When I put my sprites and bg into the same file everything
showed up nicely. Thanks to you Celius and everyone else here who helped
me get off the ground