nesdev.com

Thank you koitsu for the wiki links, hadn't read those pages... that's really cool that info is available!

By horizontally, I meant that bit2 of $2000 was 0. After looking at that PPU Registers wiki page again, it says that bit determines how the CPU writes to VRAM. So writing to VRAM is filling that buffer with info and then the PPU reads that RAM buffer while drawing a screen? If so, I'm sorry for my mistake. But mistakes are ok.

Ahh! So that's much better! We just have to disable rendering when the PPU is drawing pixels, from pixel 192 to pixel 255, on any scanline! Sigh , I thought your 'x' was just a variable name, but it also was specifying that the limit you were trying to teach is a horizontal limit. So, that is only necessary to protect sprite locations? Thought you said it also affected the attribute tables...

A solid bar at the bottom of the screen has never appeared for me.

My code is now 16536 cycles; it's plenty quick for just updating the screen.

Thank you for your recomendation! I'll definitly think about this... time for lunch.

The 16,536 cycles need to happen while rendering is turned off. Turning rendering off and on rapidly will cause flicker, which could trigger seizures in sensitive players. If you want to update anything without cutting to a blank screen, you'll need to break the update into shorter chunks that fit into 2200 cycles or so. For example, the Action 53 menu and 240p Test Suite help system update one 128-byte line of VWF text per frame, taking roughly a third of a second in all to get the new text up. I guess you could heavily letterbox the display so that only about 120 scanlines are visible in order to increase the update time every frame, but I doubt that'd go over very well.

_________________
Pin Eight | Twitter | GitHub | Patreon

Sorry again lidnariq. It was supercat who told me:and I made another mistake thinking "attributes" meant attribute tables. But, now it makes sense that I don't need to worry about 192>=x<256 bc we aren't using OAM while the screens are being drawn. Sprites are disabled.

I don't want the screen to blink either.
So lidnariq and tepples, you both recommend portioning screen drawing inside of vblank. But, it is also possible to avoid the blinking buy turning rendering on late?

Hmm... I'll have to spend time with the wiki, I guess... currently, I'd like to draw the screen all at once, but you both are recommending otherwise.

Turning rendering on late poses two problems:

1. The position of all the tiles in the background will be affected by the position of the beam when rendering starts. If you know where the beam will be, this can be accounted for, but most techniques of figuring out where the beam is (e.g. sprite 0 hits) would require that rendering already be on.

2. NTSC machines will bounce between two chroma phases if rendering is enabled at the start of line 20, or cycle among three chroma phases if it isn't. For most kinds of display content, cycling among three will create an annoying shimmer effect.

While there are ways by which those problems can be overcome, it's probably easier to try to steal time at the bottom of the screen by disabling rendering early.

Thank you supercat. When you and lidnariq say "early", does that mean rendering should be disabled before pixel 8 on scanline 0 (when horiz (v) is first incremented)?

No, that would only give me two cpu cycles... so maybe should rendering be disabled on scanline -1? Is it possible to disable rendering near the end of vblank? Guess I'll try that.

If you draw e.g. a solid line at the bottom of the "interesting" part of the screen using background tiles, and place sprite 0 so that it hits that line, the "sprite 0 collision" flag will go high when scanning reaches that part of the screen. If you wait for that flag to go high and then disable rendering, you'll be able to render whatever you want provided that before the end of vblank you reload the OAM and re-enable rendering. Note that if you fail to re-enable rendering before the end of vblank, your background tiles will likely appear shifted vertically. Note that this or other factors may result in the sprite zero trigger failing to occur. You should probably arrange things so that if that happens and the NMI fires, the game can recover, but that otherwise the NMI will do nothing.

So this is a reply about how to successfuly disable rendering late to my question about disabling rendering "early"? After being confused for a bit, and then rereading your previous reply, that is my question. Just trying to understand...

Vertical blank starts (and rendering stops, even if otherwise enabled) when the beam gets very close to the bottom of the screen. If there's a point higher on the frame beyond which everything just shows the background color, however, one can disable rendering for the balance of the frame without causing visual disruption because everything on the frame will either have been drawn already (so nothing afterward would affect it) or simply show the background color (which it would do whether rendering is on or off).

The goal, then, is to disable rendering at a point which is late in the frame (after everything of interest has been drawn), but earlier than the point when rendering would otherwise stop (the beginning of vblank).

Ah, thank you so much supercat! Understand "early" so much better now! Think I understand now why my >16k-CPU-cycles screen drawing code is way to many cycles... drawing a solid line underneath the "interesting" part would only give me a row of 16x16 pixel metatiles so about a little less than 1818 CPU cycles to draw part of the screen and reenable rendering... I guess then vblank could draw part of that screen too. So, I'll follow lidnariq's and tepples' advice and draw my screen in sections. ! !! But, when drawing the screen in sections after the first little section is drawn, vblank drawing can be skipped bc, since most of the screen will be blank, we'll be able to draw so much more of the screen! This is so exciting!

Was thinking maybe we could just draw the solid line at the top of the screen in those 1818 cycles so that most of the next frame could be used for drawing the screen, but then that would cause a blank screen to be displayed and blinking to occur, I guess. This will be fun to attempt.

You still have to mind that OAM refresh bug though... OAM corruption doesn't happen when you disable rendering, it happens when rendering resumes, so even an OAM DMA won't save you from that.

From my understanding, the bug hits when the OAM address changes, hitting the old and/or new row. If one sets the address to zero before an OAM DMA, the corruption would occur (if it's going to at all) just before the DMA operation.

I won't pretend I know the details, but my understanding is that there's nothing you can do to prevent corruption (or make it happen before the DMA) if you have disabled rendering at a "bad time". Maybe there actually is some sort of magic trick that will fix it, but I seriously doubt it's as simple as setting the OAM address to 0 before the DMA, because that is what 99% of people do already and OAM corruption is still a thing.

Yes, if you have disabled rendering at a "bad" time, the only thing that will fix sprites is rendering another screen with garbage sprites.

I guess maybe it has something to do with what Visual2C02 calls "spr_ptr", but "spr_addr" is what is set by writes to $2003.

Maaaaybe you just need to turn off rendering at a "good" time, such as by letting rendering end naturally at Y=240, in order to let sprites work at all again.

After reading about changing lda (frog), y into lda frog, y to save a cycle, and reading that I would have to keep updating that frog address to change memory locations... I felt the only way to do that would be to use PRG-RAM. So after trying to set up PRG-RAM, the nes file assembles, but Mesen shows that $6000-$6FFF is "Save RAM" and our ROM is extremely conveluded... i.e. it doesn't seem to be correct (like reset at $C000 starts with many brk in the debugger, while it is correct in the .lst file). My question is: can this easily be fixed? My questions are: is PRG-RAM the same as RAM? Like, I can't initialize it before the game starts? That would mean we'd have to... it wouldn't work like writeable PRG-ROM? So, is it not possible to save a cycle on the NES like I read about on "6502 Hacks" by Mark S. Ackerman?

This would be so much faster if this was possible bc the y register wouldn't have to be reloaded... it's much quicker to reload the x register with tsx, since rendering is off. lda (frog), y could be lda frog, x... I was hoping that at least.

final edit: makes sense now bc lda can be assembled as an absolute. Sorry.edit: I don't understand how that would even be possible since frog in lda (frog), y is a 16bit pointer and frog in lda frog, x is an 8bit address. Doesn't make sense... but, maybe that doesn't matter.

After moving the_function that needs to be in PRG-RAM into an unused bank, and writting a short new-function to copy the_function into an appropriate spot in bank 0 of PRG-RAM and change its jmp correctly, and creating a label to mark that appropriate spot... the game assembles, but reset: still begins with a bunch of zeros. Any idea why? Is it not possible to run functions after they land in PRG-RAM?