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?
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?
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?
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.
Indeed, that's the real question!
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?
Ahh.. but you guys are assuming the data being built to the buffer needs to happen in a single frame. I never said that
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.
Maybe it's to load an entire tile map at once.
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.
I do wonder if any games actually do update the entire tile map every frame instead of just parts that need changing.
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.
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?
The result is coarser, but far less "crawly" than Hydlide's scrolling.
Alp wrote:
Speaking of Hydlide, what about updating every 6 frames?
The result is coarser, but far less "crawly" than Hydlide's scrolling.
You could totally get smooth scrolling with CHR-RAM and a few sprites on the side.