This is really interesting! Thanks for sharing it, and for taking the time to code it.Fiskbit wrote: ↑Mon Dec 21, 2020 1:05 am I spent about 4 hours putting together a proof of concept using MMC1 and 32 KB of CHR-RAM, currently just animating the waterfall. It targets PRG0 (PRG1 will likely require changing some addresses). It uses 4 KB CHR mode and swaps the entire background table at once (between banks 1-4). The automap will theoretically work with it, but they may have conflicts that need to be resolved, and the automap graphics will have to be drawn into all 4 banks, which may be a pain when doing a scroll. I leave further work as an exercise to the reader. I'm maybe half confident the code is bug-free, but make no promises or guarantees. Anyone is free to use this code for any purpose, commercial or otherwise. I've included the targeted assembler, snarfblasm; I believe this is the version we use for Z1M1. Usage is "snarfblasm.exe animate.asm".
Edit: One thing that could prove to be an issue in the code as-is is the location I hijacked to do the bankswapping. It's actually further into rendering than I expected, though it does seem to only ever happen in the HUD. Might be best to do that earlier and with an explicit mode and pause check. It's not a problem now, but could be a pain depending on how you do the automap or how much code you add before the current swap.
I didn't know about this kind of NES 2.0 header of sorts, nor about the extra flags at the header's tail.
I took a quick glance and test at this code, and for sure it's something really interesting to see in execution.
I went ahead and converted your Snarfblasm ASM code to work with xkas, I have attached the xkas ready file in this post.
It should work out of the box with Zelda Redux's repository:
https://github.com/ShadowOne333/The-Leg ... elda-Redux
Simply put the animation.asm inside the gameplay/ folder, and add the line in the main.asm code, then run make.bat.
As for questions about your animation code:
- From what I was able to gather from your code, is that it allows for 256 bytes of data to be transferred over to the background PPU at once? Is that 256 bytes (as in 0x256) or just 256 (0xFF)?
- If I understood it right, you are basically transferring the specific waterfall tiles you want into the PPU $1890, correct? Not really the whole background tiles?
- As a last question. For the Automap tiles, would they need to be copied over to RAM in each animation frame? From what I see, it seems that the whole background page is being changed to that of other banks (which makes sense). Would another PPU transfer be needed specifically for the Automap tiles? Or could the whole top part of the background be possible to be left as is, and only modify the rest of the tiles starting on the stairs of the overworld tiles and onwards?