Screen 4 - vram usage

those routines need to be highly optimized because, as you saw, the process of setting vram ptr, is somewhat complex and slow, it does involves a lot of bit manipulations like shifts, masking etc. it does need to be in asm.

I must admit that you have a certain talent for distorting reality. ^^
The official V9938 document clearly defines what the pages are: https://map.grauw.nl/resources/video/yamaha_v9938.pdf.
It may not be *your* definition of a page, but that doesn't change the fact.

There is no talent. If you knew the meaning of the term abstraction you should agree with my observation.
It's not talent it is only a correct application of the term "abstraction" that mean a sort of hiding the details in the broadest range. and the vdp does not hide nothing instead add complexity and require depth knowledge of how it does work. the opposite of abstraction.
I've also told about an example of true abstraction, if you try to understand the meaning of the my previous post instead of blindly reporting the texts you found in the v9938 docs, there is a chance that you understood what does "abstraction" mean in this case. ;-)

The fact is not changed. It simply say that you can see the registers AS a PAGE concept, not that the VDP has a page concept itself in its design. Again you did not understood nothing and only blindly reporting the docs. It is *YOUR* interpretation of the docs that is clearly wrong.

It was no my idea to show the docs to prove the page concept, it was yours.
I simply replyed that the docs you reported prove my point, not yours, that is the vdp has no page concept at all.
If the vdp had such page concept you would have the notion of page both in vdp commands (and as you said, there is not) and other operations. But clearly the docs do not mention any register related to pages nor in command nor in vram I/O operations. they only "suggest" that those Y values,or R#2 register can be "thought" as vram pages. But it is a concept that the coder, not the vdp itself, has.

I can say the same apply to you previous docs you posted to prove your point.
Facts are facts.
One can search the "page" word througout the v9938 or any other docs with the intent to prove that vdp has page concept, but the facts prove the opposite.

Facts are that:
- There is no vdp register that contains the notion of page. (obviously because the vdp does not have page notion)
- There is no vdp command that contains the notion of page. (obviously because the vdp does not have page notion)
- R#2 values are *ONLY* bits, used to form the base address containing the pixels informations of the first scanline you see on the screen. No other purpose.
- By contrast to the inexistent page concept, when the vdp uses some abstraction this is is clearly seen in how registers are implemented, as in the case of X-Y registers for vdp commands, that has the notion of logical pixel coordinates (and IN THIS CASE you write x-y coordinates (that is the meaning of "abstraction"), not strange values derived from how mapping between pixels and vram bytes are laid out ). Otherwise if R#2 is the page why i cannot simply write 0,1,2,3 on it instead of a a value that result in multiple of 1K Blocks? Maybe the VDP pages are 1K of size ?
- The notion of page is a way to think the screen layout, useful for developers/users but has the same meaning for the vdp that a double floating point IEEE value has for the z80 or 6510 or 8086 (they are only bytes).
- the vdp docs suggest a way to interpret the R#2 bits as page as it does for Y coordinates (0-255 page1, 255-511 page2 and so on.