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.
Kasumi wrote:You could even write half a row, half a column, then the other half of the row, the other half of the column. It's not a good idea, just saying it because things aren't so rigid as you seem to be imagining.
One of my programs does exactly that to draw a box:
Set the address to the top left and set the increment to +1.
That's so cool tepples! I can't wait to play with the non-rigid NES PPU!
edit: Ok, I think I understand why yall used a variable to keep track of what you've written to $2000 PPUCTRL; it is a write-only register, right? And so instead of reading it you keep a copy of the last byte you've written to it... I think!
So, when my PPU is incrementing by 32 after each write does it always do that forever... like can it automaticly start at the top of the next row? Or do I need to first set the address to zero?
You have to write a new address to $2006. It's especially annoying in whatever directions you're scrolling in. In 29 cases out of 30, you have to set the address again to write a whole column. In 31 cases out of 32, you have to set the address again to write a whole row.
Kasumi wrote:You have to write a new address to $2006. It's especially annoying in whatever directions you're scrolling in. In 29 cases out of 30, you have to set the address again to write a whole column. In 31 cases out of 32, you have to set the address again to write a whole row.
Hmm... what I said was misleading. If you only scroll horizontally, you'll only need to write the starting address for each column. You'll never need to write two for one column.
Same if you only scroll vertically, except replace column with row.
It's only an issue if you do both, which you are not. You still do need to write a new address for each NEW column, but there's much less math involved there. I apologize, not quite sure what I thinking in the last post.
Kasumi wrote:Hmm... what I said was misleading. If you only scroll horizontally, you'll only need to write the starting address for each column. You'll never need to write two for one column.
Same if you only scroll vertically, except replace column with row.
It's only an issue if you do both, which you are not. You still do need to write a new address for each NEW column, but there's much less math involved there. I apologize, not quite sure what I thinking in the last post.
Thank you Kasumi! : ) I was dissappointed in having to write the address for each new column... but it is really ok now... it is should be possible for me to do! I'm looking forward to making this work for two columns. And then there will be a point where I should not make a column until it is needed... or, hey, I can create the column in my buffer and then wait to draw it on the screen.
sigh... why would my rom be built with the wrong chr screen?? In FCEUX 2.1.5's PPU viewer it shows that I've loaded the same pattern table for both screens... in my code there is:
.incbin "lvl1\lvl1.chr"
; Fill the rest of the first CHR-ROM block with zeroes.
.align $1000
; Here begins the second 4K block. The sprites (all one of them) get their data
; from this page.
.incbin "Character3.chr"
; Fill the rest of the CHR-ROM block with zeroes, giving us exactly 8K of data, which
; was what we want and need.
.align $1000
; now we have 16 banks of 8K CHR-ROM. (actually 32 banks cause we are using 4K files)
Why isn't Character3.chr present in FCEUX 2.1.5's "PPU Viewer..."? It looks like lvl1.chr is there twice!
Are you using a mapper? Have you selected the appropriate CHR-ROM banks? If you're using the MMC1 in 4KB CHR mode you might get the same 4KB mapped twice if you didn't explicitly switch the 2 4KB pages you want to use.
tokumaru wrote:Are you using a mapper? Have you selected the appropriate CHR-ROM banks? If you're using the MMC1 in 4KB CHR mode you might get the same 4KB mapped twice if you didn't explicitly switch the 2 4KB pages you want to use.
And/or have you written the right value to $2000 so that the sprites and background come from different parts of CHR?
lidnariq wrote:have you written the right value to $2000 so that the sprites and background come from different parts of CHR?
I think this wouldn't change what's displayed on FCEUX's debugger, though.
3gengames wrote:Why not make one big 8/16/32/64/128KB file and just INCBIN that instead of messing with tiny 2KB char files and such?
If you have different tilesets for different levels for example, it makes sense to use smaller CHR files. I even have individual CHR files for each enemy/object, for example. This way I can easily rearrange them without the aid of graphical editors, or even calculate banks numbers or tile indexes using labels, instead of using hardcoded values. It's more organized (which is the same reason most people don't use a single huge ASM file for the whole game).
He's using MMC1 so the highest resolution is 4KB, and is using CHR-ROM, it's much easier to do a LUT to pick the right graphics bank per level unless he uses CHR-RAM or a mapper like MMC3, especially since he's having troubles. But still, besides the point. FCEUX does not change what it displays based on $2000 value...just tested. So be sure you are picking both chunks in 4KB mode.