Flipping background tiles?

[tepples]

And on the NES, it's the other way around: you can flip sprites but not background tiles. You can flip sprites because the OAM is on a separate bus, but you can't flip background because there isn't enough space in the attribute table to store a flip attribute.

AMIGrAve: Could you attach a mock-up of the picture that you're trying to display on the NES?

[rainwarrior]

there isn't enough space in the attribute table to store a flip attribute.

Well, there is 32 unused bits interleaved with the last row. Could have stored a flip bit per column there.

[AMIGrAve]

AMIGrAve: Could you attach a mock-up of the picture that you're trying to display on the NES?

Sure, it will be a perspective grid that will looks a bit like this:

[tepples]

Yes, mappers would allow splitting that into top and bottom halves and serving each from a separate bank of CHR ROM.

[AMIGrAve]

Yes, mappers would allow splitting that into top and bottom halves and serving each from a separate bank of CHR ROM.

Thanks!

And for triggering the event at mid frame in order to do the bank switching, is it preferable to use the sprite 0 or do you advise a particular mapper that allows to trigger an IRQ or something at a given scanline ?

[tokumaru]

If you'll already be using a mapper with decent CHR bankswitching, better use one that also has scanline IRQs. To split the screen with sprite 0 you need to wait for the hit in a loop, which wastes CPU time. IRQs on the other hand can interrupt the program when the desired scanline is reached, regardless of what it's doing, and after the split the program resumes as if nothing had happened.

[AMIGrAve]

If you'll already be using a mapper with decent CHR bankswitching, better use one that also has scanline IRQs. To split the screen with sprite 0 you need to wait for the hit in a loop, which wastes CPU time. IRQs on the other hand can interrupt the program when the desired scanline is reached, regardless of what it's doing, and after the split the program resumes as if nothing had happened.

Thanks!
I just found the list of mappers with support for scanline IRQs maintained by rainwarrior on the nesdev wiki. Cool!

[rainwarrior]

I just maintained the category page itself a little. I should not be credited for maintaining the list, a lot of other people did the real work on that one.

[tokumaru]

The MMC3 is probably the best choice in this case. It has reasonably fine CHR bankswitching (2KB for one pattern table and 1KB for the other) and a decent scanline counter. It's also very common and there are implementations of it for homebrew games. The only downside is that since the scanline counter functions by counting pattern table accesses, you can't use sprite tiles from both pattern tables when in 8x16 mode, because that confuses the counter. Sprites must come from one pattern table, and backgrounds from the other.

[Lazycow]

It's also very common and there are implementations of it for homebrew games.

I'm not sure if I understand, do you mean that are chips available that do the job of a MMC3 without the need of grabbing these chips out of other carts?

[tokumaru]

Yes. INL has all new hardware for many mappers, including the MMC3.