8x16 and whatever else unreg wants to know

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
koitsu
Posts: 4218
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: 8x16 and whatever else unreg wants to know

Post by koitsu » Thu Jun 27, 2019 2:20 pm

I'm coming in late, but: you generally do not:

1. Try to write an entire nametable (read: entire screen) worth of data in VBlank/NMI -- reasons have been covered already I think, but it takes too long / too much data
2. Turn off rendering unless you are absolutely positively 100% certain you know why you need to do it. In general you need to design your game/thing so that you do not have to do this.

I don't understand why you're trying to do #1. I don't think Tepples does either. Is this because you want to make it easy on yourself? If so, you're not going to win this battle. You need to learn how to update the edges of the screen (left and right columns when using the increment-by-32 mode of PPU addressing). Yes, writing the engine code that does all of this is (IMO) complicated and "not fun", there's a lot you have to keep track of.

Does this game/thing use panning/scrolling at all? If you're trying to do everything in single-screen and you aren't using panning/scrolling, my advice is: don't. Make use of the memory in the adjacent nametable and flip-flop between them using bits in $2000. You draw to the one that isn't visible, then switch to it, rinse lather repeat. This is effectively what's called "double buffering" (probably a term you've encountered somewhere before).

tepples
Posts: 22012
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples » Thu Jun 27, 2019 5:15 pm

If you're trying to animate a lot of stuff within the nametable, as in the FMV demos "Motion" by Chris Covell and "Bad Apple!! PV-FC 2" by someone else, then you should probably be using double buffering.

supercat
Posts: 161
Joined: Thu Apr 18, 2019 9:13 am

Re: 8x16 and whatever else unreg wants to know

Post by supercat » Thu Jun 27, 2019 10:14 pm

koitsu wrote:Does this game/thing use panning/scrolling at all? If you're trying to do everything in single-screen and you aren't using panning/scrolling, my advice is: don't. Make use of the memory in the adjacent nametable and flip-flop between them using bits in $2000. You draw to the one that isn't visible, then switch to it, rinse lather repeat. This is effectively what's called "double buffering" (probably a term you've encountered somewhere before).
Scrolling can be combined with double-buffered animation provided one isn't scrolling too fast, by using a few frames to draw new screen content in the parts of the nametable that aren't being displayed, and then in the last VBLANK update the areas that overlap the old frame and switch to showing the new one.

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Mon Jul 01, 2019 3:16 pm

koitsu wrote:If you're trying to do everything in single-screen and you aren't using panning/scrolling, my advice is: don't. Make use of the memory in the adjacent nametable and flip-flop between them using bits in $2000. You draw to the one that isn't visible, then switch to it, rinse lather repeat. This is effectively what's called "double buffering" (probably a term you've encountered somewhere before).
Thank you koitsu for recommending double buffering! :D It should be all set up now, but there is a weird problem, Mesen switches to delay-display the nametable that we're writing to the instant that $2006 is completely written to (after the low byte). By delay-display, I mean that nametable 1 is highlighted in Mesen's Nametable Viewer after $2400 is written to $2006, and also that nametable 1 is displayed the next frame. This is weird bc $2000 is never changed... like you said, "Make use of the memory in the adjacent nametable and flip-flop between then using bits in $2000."

My goal was to see the entire screen drawn in nametable 1 b4 flip-flopping. Now it's way confusing. Is the NES susposed to behave this way? If so, why? :) And, otherwise I guess Mesen has been set up incorrectly by me. :(

edit: Also, the wiki didn't mention anything about $2006 changing what nametable is displayed. So maybe I've set Mesen up incorrectly?

lidnariq
Posts: 9488
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: 8x16 and whatever else unreg wants to know

Post by lidnariq » Mon Jul 01, 2019 3:35 pm

$2006, $2005, and the two nametable bits in $2000 are all ways to access the same thing. nesdevwiki:PPU scrolling

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Mon Jul 01, 2019 3:48 pm

lidnariq wrote:$2006, $2005, and the two nametable bits in $2000 are all ways to access the same thing. nesdevwiki:PPU scrolling
Ahha! Thank you lidnariq! :D I forgot they shared an internal register. :oops:

edit: Maybe that page could be linked to from the PPU registers page in the $2000, $2005, $2006 register sections... or on the PPU registers page maybe say something like, "these share an internal register"... that would be really helpful, IMHO. :)

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Wed Jul 10, 2019 3:12 pm

Now, the blinking is gone since the game now draws a 5th of each screen inside vblank! Thank you all so much! :D Time to decompress my sister's RLE... I'll be silent unless questions arrise. :)


edit: (this is an edit bc it's not important) our game isn't that efficient bc it does draw an 8th of each screen inside of vblank. Not a 5th, I'm sorry for my mistake.



final-edit-note: it actually draws an 8th, not a 7th, so the first edit was adjusted accordingly. :oops:

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Tue Aug 06, 2019 8:35 am

unregistered[color=#FF8040], on pg. 98,[/color] wrote:Ok, so asm6 is limited to 64 hex codes following its .hex. (i.e. When our game assembles, the cursor at the end of most of our .hex lines is in column 135. The hex codes start, after .hex, in column 7. 135-7=128. 128/2=64.) Why this limitation-have no clue right now. With 65 hex codes per line asm6 gives, "Not a number."
Now, it's evident that while, 64 hex codes following asm6's .hex will assemble, the 64th hex code is incorrectly tranferred to the ROM during assembly. The 64th code on the first RLE line in our game is #$BC but it was assembled as #$0B, #$0C... so after limiting each line of the first screen to 62 hex codes they assemble just fine. :)

It makes some sense that each line would be limited to less than 64 hex codes, but we're using 62 per line bc RLE uses 2 hex codes for each different value-set (though I'm sure 63 would work just fine too).

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Thu Jan 09, 2020 10:03 am

Hmm... Why does the PPU have to idle on “Post Render Scanline 240”? My code barely fits inside vblank and this extra scanline would provide more breathing room... I’m sure this has been asked be4, but wow: Idle for an entire scanline and setting the vblank flag after and we can run PPU operations somehow on 240! :shock: Haha, this is crazy. :!:

edit: Though, getting to take a break is wonderful so I’m kinda glad the PPU gets to rest. :)

tepples
Posts: 22012
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples » Thu Jan 09, 2020 6:44 pm

In this post, turboxray called the Famicom "a half-baked design" intended in part to beat Sega to the Japanese market. That's why.


EDIT: Attribution

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Fri Jan 10, 2020 9:44 am

Thank you tepples, that’s very interesting. :D

I am thinking I don’t have to draw entire tiles at once... the math seems to work much better when just caring about pixel count... in the process of changing the draw functions... it should allow more breathing room. :)

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Mon Jan 20, 2020 4:04 pm

Hmmm... is it not possible to write part of a tile to the PPU and then finish writing that tile later (the next vblank)?

The partially written tile, after being fully written, is always terrible... maybe it’s my code logic. :)

tepples
Posts: 22012
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: 8x16 and whatever else unreg wants to know

Post by tepples » Mon Jan 20, 2020 6:12 pm

If you write part of a tile, wait for vblank, and write the other half of the tile, the PPU will display the partially written tile as usual.

This behavior is useful in certain scenarios involving displaying large amounts of text, as its two bit planes are displayed in two different places, once with each of two palettes. Writing half of the tile writes the pixels that appear in one place, and writing the other half writes the pixels that appear in another place. The Action 53 menu uses this technique, where the top half of the information panel uses attribute 2 (palette indices $3F09-$3F0B) and the bottom half uses attribute 3 (palette indices $3F0D-$3F0F).

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

Re: 8x16 and whatever else unreg wants to know

Post by tokumaru » Mon Jan 20, 2020 6:34 pm

unregistered wrote:
Mon Jan 20, 2020 4:04 pm
Hmmm... is it not possible to write part of a tile to the PPU and then finish writing that tile later (the next vblank)?
The pattern table is just regular RAM (if you use CHR-RAM, of course), there's nothing requiring you to update entire tiles at once. The only side effect of partial tile updates is that the tiles will be visible in their half updated state for a frame if they happen to be on screen... So unless you're doing this as part of some kind of visual effect (e.g. the tileset is morphing into something else), you'll only want to do this with tiles that are not visible.
The partially written tile, after being fully written, is always terrible... maybe it’s my code logic. :)
There's probably some kind of alignment problem with the addresses when you're resuming the transfers.

unregistered
Posts: 1071
Joined: Thu Apr 23, 2009 11:21 pm
Location: cypress, texas

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Wed Jan 22, 2020 10:44 am

Thank you tepples and tokumaru! :D Yes, these tiles aren’t displayed yet... just looking at Mesen’s CHR Viewer; the problem definitely was address alignment problems. But, it’s getting aligned! :)

A side note: why did MOS Technology not allow their lda to use Absolute Indirect addressing? adc and jmp can use that; it’s not fair! :( It’s cycles wasted changing y between 2 different values... sigh :wink:

Post Reply