You could use the R#25 "trick" to get double buffering on the sprite frames. Updating the big guy (about 8kb I guess) could be possible with BMXL but would require probably a little more than one 60 Hz frame.
Transfers VRAM to VRAM have the inconvenience that there are many animation frames and they don't fit all in VRAM. At least some frames must come from ROM during game play.
Earthquake is the worst case scenario: 128x144 = 9216 bytes.
I don't know exactly but I suppose there is around 100 animation frames per character.
Even worse: V9990 does not have the flipping sprites capability. When players change side we need all sprites flipped horizontally. So we need all those frames doubled = 200 frames. Invert them by software in real time I don't think would be possible.
But for the small characters (80x112 px) the story is different and may be achievable.
Even worse: V9990 does not have the flipping sprites capability. When players change side we need all sprites flipped horizontally. So we need all those frames doubled = 200 frames. Invert them by software in real time I don't think would be possible.
I seem to remember that there is some trick to flip the sprites in VRAM using BMXL, I think.
GhostwriterP can explain it all better than me.
Well, with BMXL you can flip sprites on the fly, no extra cost. Still leaves the problem of the large number of frames indeed.
Actually, doing some numbers in my head, it might technically be possible to update an Earthquake sized character within one frame on R800. Though it requires a bit more hustle. You split the workload in two. Half of the character is stored in VRAM the other half in RAM. The VRAM part can be updated with BMXL a 4608 bytes and in the mean time you can update the other part with R800. For 4608 bytes it should be doable to achieve this including on the fly mirroring (it takes only 4 extra cycles to swap the nibbles, and reading data backward is just as fast as forward). So 30 fps may be achievable, especially if other character is smaller.
To tackle the data space requirement, perhaps it is possible to filter out and group the sprite patterns that do not changes over frames in a smart way and reuse among frames. Also it could be worth looking into layering of sprites. E.g. looking at Earthquake the legs do not seem to change, same for the hand and chain part going up and down. Of course this will all require a lot of hustle and maybe in the end it is not enough... anyway my 2 cents if you ever serious in pursuing this
You split the workload in two. Half of the character is stored in VRAM the other half in RAM. The VRAM part can be updated with BMXL a 4608 bytes and in the mean time you can update the other part with R800
To the best of my knowledge I thought that when you are doing VDP commands you cannot access VRAM with the CPU. The CPU is free for statements on registers or with the RAM. Is it true? Or is true only for 9938/58? V9990 is a different story?
Also I thought the R800 is slower than the Z80 on VRAM operations. OUTI is 18 cycles on Z80 vs 27 (?) cycles on R800. Am I wrong about this?
On V9938 / 58 you can do CPU VRAM access during command execution without problems. I assume it is the same on V9990.
R800 access speed of non-V9958 I/O ports is 10 cycles (@ 7.16 MHz) per operation. Much faster than Z80.
On V9938 / 58 you can do CPU VRAM access during command execution without problems.
Yes, it is indeed possible to do CPU VRAM access on V9938/V9958 during commands. But beware that, as a result, the ongoing command speed does slow down, as much as 50% in some cases.
That's what I mean. Impossible is not the right word. It has no speed advantage.