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.tokumaru wrote: ↑Fri Jan 31, 2020 4:34 amYou'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!).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 #.
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?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.
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.