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

unregistered
Posts: 1076
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 31, 2020 4:48 pm

tokumaru wrote:
Fri Jan 31, 2020 4:34 am
unregistered wrote:
Thu Jan 30, 2020 4:49 pm
tokumaru, this is my lack of experience response: But pla is 4 cycles. That’s twice as many cycles as lda #.
You're right, lda # is indeed as fast as it gets - I didn't know you were doing that. Few people use that for VRAM transfers because of how much memory it needs (5x the amount of actual data actually being transferred!).
8 extra bytes bc: 1 4kb CHR file is 4096 bytes. (4096 bytes / 256 tiles = 16 bytes per tile.) 4096 / 12 frames = 341.3333. So our function writes 342 bytes per frame... 342 bytes * 12 frames = 4104 bytes. 4104 - 4096 = 8 extra bytes.
Wait... so you have one unrolled function that writes 342 immediate values to VRAM? That function is 1710 bytes (plus 1 for the RTS) long! Do you have the RAM for that?
Yes. And there is definitely enough room for that bc #1711 = #$6AF and MMC1 provides me 2kb of save RAM... so we still have over 1kb free. :)

edit: maybe 2kb is wrong, but according to Mesen there is a #$2000 size space of saveRAM available; though that could be mirrored... I don’t know. Haven’t ever tried to write to the second half.

final-edit: Ah, it’s not mirrored. There are some !00 bytes in the first part of saveRAM’s second half... they must have been mistakenly written. And, I believe that MMC1 provides me with 8kb of saveRAM bc I shared your concerns that there wasn’t enough RAM, but the nesdev-wiki provided a guide to that extra RAM-space for MMC1. :)

User avatar
tokumaru
Posts: 11858
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 » Fri Jan 31, 2020 5:38 pm

unregistered wrote:
Fri Jan 31, 2020 4:31 pm
Thank you tokumaru! :D (Going to try your #2 option/suggestion.)
Yeah, I'd probably go with that too. And make it slightly more flexible even, by always writing an RTS after the last transfer, and remembering that position in order to restore the LDA once the transfer is done. That way the routine could be used to transfer any arbitrary number of bytes.
I didn’t want to block VRAM transfers... just wanted to add a beq to the end of the VRAM transfer function to skip the final 8 bytes written. :)
I see... That would never work though, because write instructions don't set any CPU flags. You'd still have to read from a memory-mapped register somewhere to get that flag. No hardware engineer would think of something that contrived for something of so little practical use. Programs themselves are supposed to keep track of how much data they move around, the hardware doesn't have anything to do with it. :wink:
I agree that it is pointless to wish for a change, but, for me, that makes the message more exciting/fun to write. :) Though, I will try to remember your wisdom.
I don't think that discussing how things could have gone is necessarily a bad thing, it can actually be fun sometimes, what I feel is bad for a programmer is when they repeatedly blame the hardware for their problems and wish it was different in order to suit their needs, instead of taking the opportunity to improve their logic skills and "outsmart" the hardware. I'm not saying you do this all the time, I'm just asking to not go down that road. If you decided to work with 30+ year-old hardware it's because you want the challenge, so just embrace it and take every opportunity you can to improve your coding skills.
Yes, good points/wisdom shared, this is for my sister’s animation so the less frames between each picture, the better. :)
Is this like, a full screen animation or something?

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Tue Feb 04, 2020 10:50 am

tokumaru wrote:
Fri Jan 31, 2020 5:38 pm
unregistered wrote:
Fri Jan 31, 2020 4:31 pm
Thank you tokumaru! :D (Going to try your #2 option/suggestion.)
Yeah, I'd probably go with that too. And make it slightly more flexible even, by always writing an RTS after the last transfer, and remembering that position in order to restore the LDA once the transfer is done. That way the routine could be used to transfer any arbitrary number of bytes.
That is a grand idea, but it’s not for me right now bc that recommendation would require keeping track of the position AND it seems to me that a branch addition would be required to counter the first 11 runs where the final rts would be overwritten with a lda #00.
tokumaru wrote:
I didn’t want to block VRAM transfers... just wanted to add a beq to the end of the VRAM transfer function to skip the final 8 bytes written. :)
I see... That would never work though, because write instructions don't set any CPU flags.
Was hoping the PPU would set the zero flag... that would be so cool, helpful, fun, and efficient! :)
tokumaru wrote:
I agree that it is pointless to wish for a change, but, for me, that makes the message more exciting/fun to write. :) Though, I will try to remember your wisdom.
I don't think that discussing how things could have gone is necessarily a bad thing, it can actually be fun sometimes, what I feel is bad for a programmer is when they repeatedly blame the hardware for their problems and wish it was different in order to suit their needs, instead of taking the opportunity to improve their logic skills and "outsmart" the hardware. I'm not saying you do this all the time, I'm just asking to not go down that road. If you decided to work with 30+ year-old hardware it's because you want the challenge, so just embrace it and take every opportunity you can to improve your coding skills.
Me agree! :)
tokumaru wrote:
Yes, good points/wisdom shared, this is for my sister’s animation so the less frames between each picture, the better. :)
Is this like, a full screen animation or something?
Yes... full screen.

User avatar
tokumaru
Posts: 11858
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 » Tue Feb 04, 2020 3:41 pm

unregistered wrote:
Tue Feb 04, 2020 10:50 am
That is a grand idea, but it’s not for me right now bc that recommendation would require keeping track of the position AND it seems to me that a branch addition would be required to counter the first 11 runs where the final rts would be overwritten with a lda #00.
Well, you are probably already keeping track of the position anyway, in the form of a pointer and maybe an index. Just save that information somewhere and you'll be able to write to that exact same location in the future. Just something to think about. If you're using this exclusively for those 2 constant amounts of bytes there's no problem in hardcoding the address of the one byte that needs changing.
Was hoping the PPU would set the zero flag... that would be so cool, helpful, fun, and efficient! :)
Well, external hardware simply can't change a flag inside the CPU. And I insist that programmers should be responsible for keeping track of how much data they write where without the hardware having to hold their hands.

tepples
Posts: 22052
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 » Tue Feb 04, 2020 4:47 pm

tokumaru wrote:
Tue Feb 04, 2020 3:41 pm
Well, external hardware simply can't change a flag inside the CPU.
For the sake of completeness, there is one exception that applies to some other applications of the 6502, but not the NES. Thus I won't go into detail about it.

User avatar
tokumaru
Posts: 11858
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 » Tue Feb 04, 2020 5:07 pm

tepples wrote:
Tue Feb 04, 2020 4:47 pm
Thus I won't go into detail about it.
So much for completeness... I honestly have no idea what you're referring to, so I can't even research on my own.

User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 508
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: 8x16 and whatever else unreg wants to know

Post by Jarhmander » Tue Feb 04, 2020 7:30 pm

tokumaru wrote:
Tue Feb 04, 2020 5:07 pm
tepples wrote:
Tue Feb 04, 2020 4:47 pm
Thus I won't go into detail about it.
So much for completeness... I honestly have no idea what you're referring to, so I can't even research on my own.
Don't worry, he's just talking about the SO (set overflow) pin that exists on the stock 6502. It's most known as one obscure feature the C64 CBM drive hardware used.
((λ (x) (x x)) (λ (x) (x x)))

User avatar
tokumaru
Posts: 11858
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 » Tue Feb 04, 2020 8:52 pm

Oh, OK, thanks for pointing that out. Now that you mention it, I guess you can technically set the I flag by generating an interrupt via the IRQ pin... But still, as a general rule the internal state of the CPU can't be directly modified by external hardware. In addition to the potential of interfering with the program being run, there's no physical interface to directly manipulate most of that internal state.

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Fri Feb 21, 2020 2:00 pm

Hmm... so the proper way to change CHR tiles is to first draw the entire new screen with the wrong CHR tiles, and then write the new CHR tiles, then switch to the new screen’s nametable and finally adjust $2000 to display the background with the new CHR tiles?

Now, after drawing and changing to the new CHR tiles before writing the screen, the displayed undrawn-screen-portion is jumbled. :( (“undrawn” refers to the old screen portion that’s supposed to be displayed with the old tiles.)

Sigh, guess we have to switch some flags around.


edit: Now my memory of tokumaru, I think, telling me about disabling rendering comes back. :oops: I’ve surly asked this before.

final-edit: After reading pages 100-102, of this thread, it was lidnariq and supercat who taught that disabling rendering for a longer-than-vblank causes the electron beam to draw nothing; therefore, if not done correctly (using sprite-0 hit at lower blank portion of screen) the visible screen gets re-drawn blank. So, disabling rendering isn’t a wise choice AND I guess I’ll try my original idea in this post.

User avatar
tokumaru
Posts: 11858
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 » Sat Feb 22, 2020 12:19 am

unregistered wrote:
Fri Feb 21, 2020 2:00 pm
Hmm... so the proper way to change CHR tiles is to first draw the entire new screen with the wrong CHR tiles, and then write the new CHR tiles, then switch to the new screen’s nametable and finally adjust $2000 to display the background with the new CHR tiles?
Whether you're gonna update the name tables or the pattern tables first, that's your call, the order really doesn't matter. What matters is that this is a lot of data (5120 bytes for 1 name table + 1 attribute table + 1 pattern table) and you have to plan how you're gonna stream all that to VRAM with enough speed and without ever displaying corrupted graphics.
Now, after drawing and changing to the new CHR tiles before writing the screen, the displayed undrawn-screen-portion is jumbled. :( (“undrawn” refers to the old screen portion that’s supposed to be displayed with the old tiles.)
I'm not sure I understand what you mean here, but jumbled graphics could mean that you're updating something that's currently visible (i.e. not the hidden buffer) or that you're accessing VRAM while the PPU is rendering.
final-edit: After reading pages 100-102, of this thread, it was lidnariq and supercat who taught that disabling rendering for a longer-than-vblank causes the electron beam to draw nothing;
When you disable rendering, the PPU just outputs color 0 (or the color pointed by the VRAM address register if it happens to be pointing to the palette area). If you need to transfer a lot of data to VRAM without blanking the picture, you'll either have to confine the transfer to the vblank period (which severely reduces your bandwidth) or selectively blank portions of the picture (usually at the top and/or bottom of the screen) to gain some extra time for VRAM transfers.

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Wed Feb 26, 2020 2:53 pm

tokumaru wrote:
Sat Feb 22, 2020 12:19 am
unregistered wrote:
Fri Feb 21, 2020 2:00 pm
Hmm... so the proper way to change CHR tiles is to first draw the entire new screen with the wrong CHR tiles, and then write the new CHR tiles, then switch to the new screen’s nametable and finally adjust $2000 to display the background with the new CHR tiles?
Whether you're gonna update the name tables or the pattern tables first, that's your call, the order really doesn't matter. What matters is that this is a lot of data (5120 bytes for 1 name table + 1 attribute table + 1 pattern table) and you have to plan how you're gonna stream all that to VRAM with enough speed and without ever displaying corrupted graphics.
Now, after drawing and changing to the new CHR tiles before writing the screen, the displayed undrawn-screen-portion is jumbled. :( (“undrawn” refers to the old screen portion that’s supposed to be displayed with the old tiles.)
I'm not sure I understand what you mean here, but jumbled graphics could mean that you're updating something that's currently visible (i.e. not the hidden buffer) or that you're accessing VRAM while the PPU is rendering.
It seems to me that the jumbled-tiles problem centers around my updating the CHR file before drawing the new screen.

“so the proper way to change CHR tiles is to first draw the entire new screen with the wrong CHR tiles” means I need to draw the entire new screen, then, after the new screen is drawn to vram (in the undisplayed nametable), I write the new 4k CHR tiles to the sprite-CHR part, and finally change nametables AND $2000 is adjusted to display background with “sprite” tiles. This $2000 adjustment hopefully won’t matter bc we aren’t displaying sprites during this time.
tokumaru wrote:
final-edit: After reading pages 100-102, of this thread, it was lidnariq and supercat who taught that disabling rendering for a longer-than-vblank causes the electron beam to draw nothing;
When you disable rendering, the PPU just outputs color 0 (or the color pointed by the VRAM address register if it happens to be pointing to the palette area).
That’s interesting; didn’t know about being able to change the blank color. :)

User avatar
tokumaru
Posts: 11858
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 » Wed Feb 26, 2020 5:31 pm

unregistered wrote:
Wed Feb 26, 2020 2:53 pm
“so the proper way to change CHR tiles is to first draw the entire new screen with the wrong CHR tiles” means I need to draw the entire new screen, then, after the new screen is drawn to vram (in the undisplayed nametable), I write the new 4k CHR tiles to the sprite-CHR part, and finally change nametables AND $2000 is adjusted to display background with “sprite” tiles. This $2000 adjustment hopefully won’t matter bc we aren’t displaying sprites during this time.
If you have a hidden name table, and a hidden pattern table, the order of the updates doesn't matter at all. You just have to make sure that all VRAM updates take place during vblank or when rendering is turned off.
That’s interesting; didn’t know about being able to change the blank color. :)
Unfortunately, that's of very limited use, since the main reason for turning referring off is VRAM updates, meaning the VRAM addresses register is busy with the transfers and thus can't point to a palette entry.

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Thu Feb 27, 2020 11:00 am

tokumaru wrote:
Wed Feb 26, 2020 5:31 pm
If you have a hidden name table, and a hidden pattern table, the order of the updates doesn't matter at all. You just have to make sure that all VRAM updates take place during vblank or when rendering is turned off.
Ahha! Yes! Thank you for helping clear my muddied thinking. :) Half of my brain was lost on solving a problem created when drawing on the visible pattern table.
tokumaru wrote:
That’s interesting; didn’t know about being able to change the blank color. :)
Unfortunately, that's of very limited use, since the main reason for turning referring off is VRAM updates, meaning the VRAM addresses register is busy with the transfers and thus can't point to a palette entry.
That’s not good, but still cool to know; thank you tokumaru! :)

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Thu Sep 17, 2020 3:54 pm

PRAISE GOD!! :D :mrgreen:

Wow! Can log in again! Thank you so much tepples, and, on IRC, Kufat, jero32, and genuisAZK (I think that’s how it’s spelled)! :D

—-

Our game uses MMC1; it’s set to use 32 PRGROM banks, 8kb of PRGRAM, and 8kb of CHRRAM. PRGROM Banks #15 and #31 are the only banks that can be switched to $C000.

We’re attempting to switch the game into drawing CHR with rendering disabled. The first 4kb CHR file is completely written correctly.

However, the second 4kb CHR file must be written after the $8000-bank is changed to #$0E. Changing banks on MMC1 requires 5 writes to ROM; and so after the first “sta $8000”, both banks are suddenly changed! :( :? The $8000-bank becomes set to bank #0 and $C000-bank is set to bank #1.

I know that only the last ROM address matters during the 5 ROM writes to change MMC1 banks.

Could this weirdness be bc we’re switching the game from writing CHR during each vblank to writing two entire 4 kB CHR files with rendering disabled?

Thank you for reading. :)


Note: Now, that the entire intro animations work, we’re reaching this problem when trying to start the actual game. The writing with rendering disabled is ok, in my small opinion, bc the screen is all black when the game should start. :)


edit: oh, yes, the game is trying to change the $8000-bank from using code inside the $C000-bank.

final-edit: replaced “from” with “using”, in edit

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

Re: 8x16 and whatever else unreg wants to know

Post by unregistered » Fri Sep 18, 2020 12:32 pm

^What would you check if the MMC1 PRG banks suddenly become bank #0 and bank #1, after the first, of 5, bank-switching writes to ROM? :)

Post Reply