This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Forced vblank

Forced vblank
by on (#183165)
If you turn off the display early, and only have 192 active scanlines for the display - you should be able to transfer up to 1000 bytes to PPU port using lda #nn, sta port? And still have roughly 16 scanlines in vblank left over, right?
Re: Forced vblank
by on (#183166)
On NTSC NES, 192 active picture lines mean 70 blank lines, or 70*(341/3) = 7956 CPU cycles. The unrolled loop you describe transfers 1 byte of data per 6 cycles, or 1024 bytes in 6144 cycles or 6144/(341/3) = 54 lines. But where will you be storing this unrolled loop, at 5 bytes of code per 1 byte of data?
Re: Forced vblank
by on (#183167)
tepples wrote:
But where will you be storing this unrolled loop, at 5 bytes of code per 1 byte of data?

In the 8KB of WRAM in the cartridge?
Re: Forced vblank
by on (#183168)
During what fraction of the 192-line (21824-cycle) active picture time will the data in the 8 KiB of WRAM in the cartridge be filled, especially with the updates needing to be spaced five bytes apart? That's less than 22 cycles per byte.
Re: Forced vblank
by on (#183169)
Indeed, that's the real question! :wink:

Since there's not much CPU time left to actually compute 1024 bytes of data and buffer them, could it be that this data is supposed to be generated by extra hardware in the cartridge?
Re: Forced vblank
by on (#183170)
Ahh.. but you guys are assuming the data being built to the buffer needs to happen in a single frame. I never said that :)
Re: Forced vblank
by on (#183174)
If the transfer into the buffer can happen over several frames, then why does a 1K transfer out of the buffer need to happen in a single frame? A moderately (16x) unrolled loop can achieve 9 cycles per byte using the 6502's aaaa,X addressing mode. This can move 1K in about 4 frames (or 6 with OAM DMA every frame) even without forced blank. If it's for a nametable, there's enough VRAM in the Control Deck to double-buffer that.

I'm just curious about the sort of game loop you'll be using this for, as a way of getting XY problems out of the way for your anticipated follow-up questions.
Re: Forced vblank
by on (#183723)
Maybe it's to load an entire tile map at once.
Re: Forced vblank
by on (#183726)
The reason of why, is kind of irrelevant. It's more, can I, and then later I'll find a reason to use it. And yes, it specifically concerns itself only with vblank one shot, and not how many other frames it takes "build it". At least, for some ideas. Form gives rise to function.
Re: Forced vblank
by on (#183731)
Yes, you can.
Re: Forced vblank
by on (#183850)
I do wonder if any games actually do update the entire tile map every frame instead of just parts that need changing.
Re: Forced vblank
by on (#183851)
psycopathicteen wrote:
I do wonder if any games actually do update the entire tile map every frame instead of just parts that need changing.

On the NES? With the exception of Hydlide, I doubt it. But anything using a TMS9918, which doesn't support hardware scrolling, direct have another option.
Re: Forced vblank
by on (#183853)
tokumaru wrote:
psycopathicteen wrote:
I do wonder if any games actually do update the entire tile map every frame instead of just parts that need changing.

On the NES? With the exception of Hydlide, I doubt it. But anything using a TMS9918, which doesn't support hardware scrolling, direct have another option.

Speaking of Hydlide, what about updating every 6 frames? :P
The result is coarser, but far less "crawly" than Hydlide's scrolling.
Image
Re: Forced vblank
by on (#183858)
Alp wrote:
Speaking of Hydlide, what about updating every 6 frames? :P
The result is coarser, but far less "crawly" than Hydlide's scrolling.
Image

You could totally get smooth scrolling with CHR-RAM and a few sprites on the side.