According to section 1.5 on page 7 it does, but only in some modes.
Bah, why does it have to be only in *some* modes? That just makes it easier to have bugs in both software and the hardware.
The GPU will also need a way to access all this memory. A 32-bit mode perhaps?
Hmm, not sure. Probably not a 32-bit mode since there is no precedence for that in the 9900 family.
I guess there are actually 3 different types of paging to consider: 1. The page accessed via the CPU-VDP interface. 2. The page accessed by the GPU. 3. The currently displayed page or pages. Each table (pattern table, name table, sprite table, bitmap table, etc.) may be mapped to a different page or pages.
Double buffering, by changing the page of the currently displayed bitmap, is important for some of the games I have in mind.
In looking at the 9938 datasheet a little, it seems the extra memory was addressed via an extra register (VR14) that the programmer had to manage. In that case it seems to make sense to use the same VR14 (currently purposely unused in the F18A) to do exactly the same thing in the MK2. The GPU would have to manage VR14 the same way the host-computer software has to manage VR14. In this case it does implement the idea of paging the 512K via the original 16K address space. This would also mean that the F18A's GPU can retain its current address space above 16K. The GPU will need its own paging register though, so it can access memory without interfering with the host CPU. The DMA will need to be expanded too.
The 9938 expanded each table's base address, so yes, each table has its own "page" reference and can reside anywhere in the expanded memory. The only problem is that I knowingly stepped into the VR8 .. VR14 area with Tile Layer 2. I was trying to say out of those registers in case I ever was to do 9938 compatibility, and look, here I am... In the 9938 VR10 and VR11 expand the base addresses for the TL1 color table and TL1 sprite attribute table. I'm not sure how to reconcile this yet, since I don't want to break any new F18A software that uses TL2.
Then there is also the problem that the 9938 only expanded access to 128K and the MK2 has 512K. For general VRAM reading/writing I can add the extra two bits to VR14, but for table base address placement it might be a problem for some tables.
Absolutely, double-buffering will be possible. I'm also kicking around ideas on how to avoid having to clear the offline buffer (although the DMA does it about as fast as possible).
Why not, for backwards compatibility, leave the addressing & extra information where it is (at 0x4000,) by default, but add in (maybe at 0xFFFF,) a register that can move that, so that you can create a single large continuous RAM block? You could use the same address, to define paging method as well. Software written for the MK1 would not be accessing that address, so the default would stay, and it would act as the software expects. But new software could change that, and thus get greater access to the increased RAM of the MK2. It would be nice, though not required, if whatever block is defined as the control block, could be non-paging or auto mirroring (if you decide to go with just having 8 pages of 64k each.) Would avoid the trouble of having the register that defines the page change when you shift pages. Could result in a page switching loop that could be near impossible to break.
With VR14 specifying the address bits above 16K, the memory is already paged through a register so it will not be a problem. It would be convenient for the GPU to be able to access the VRAM in 64K chunks (i.e. using the full 16-bit address of the 9900), but keeping the memory access as-is presents the least problem all around.