tepples wrote:
[list][*]I'd imagine that the PIC introduces latency. Thus mid-scanline bankswitching might be a bit tougher.
Yeah, without knowing the amount of time taken by the PIC to do it, it'd be guesswork. When it's finalized I'll document the timing, and also release the source for the register handling for reference. It should be accurate within 1 or 2 6502 cycles for sure.
It's also feasible to have the PIC handle bankswitching independantly, with a frame being reset by an NMI acknowledge from the NES. It could save the NES a lot of work if that's done mid-line.
Quote:
[*]In addition, the VRAM bankswitching is 8 KB like CNROM, meaning you can't easily do a SMB2-style background CHR rotation loop, but if your scrolling isn't really fast, then perhaps you might be able to do it Battletoads style, with a hyper-unrolled copy of 8 tiles per frame.
Yep. Also the RAM bankswitching gives a new advantage (assuming you need or want to animate everything at once), because you can have the partially-updated version of the bank only switched in during vblank. Like double-buffering. So you can spread an update across several frames for really huge changes with no visible tearing.
But yeah, these are all important points to keep in mind for anyone who's used to working with the ASIC-based mappers. Those are the main disadvantages in comparison to MMC1,3,etc. But I think a program that plays well to Squeedo's strengths could do things never seen before on NES. Especially when running useful code in the PIC, it's like parallel processing. Other than when playing sound with my synth code, the PIC has tons of idle time to put to use. It's just up to figuring how and what to make it do, heheh.