Screen 4 - vram usage

the fact they reused the registers by using only higher bits is only to avoid the inconsistency that would arise if they used the total n. of bit of available.
the R23 has no direct relation with page concept: it is here to allow hw scrolling and it was reasonable that it worked on a single screen page at once otherwise it is only a duplicate of R#2. Clearly.

First: i do not want anything. i only see what is it here. without any interpretation. the R2 register is a register.stop.
as said the requirement of using only higher bits in r2 in higher modes is only to avoid the MESS that otherwise will occour (and you described above) if you could use other less significant bits in the register. And this is another strong prove of my point of view.
If the vdp was meant with page concept in mind instead of raw addresses there would have no been no need to mask out less significant bits in bitmap modes, they could have worked as i said, with the page number instead of addresses.
And please: this is not a way I WANT vdp to work. it's the only way it could have worked in a reasonable way if the designers had wanted to have a page concept instead of raw addresses. the way it is working is reasonable only to you ;-) if see a page concept here,
when vdp designers wants an abstraction they did it correctly: as already clearly demonstrated in the case of the vdp logic commands: here the designers wanted this abstraction and they created it correctly without bit masking depending on screen mode (what kind of page abstraction is if you need to take in account the screen mode detail ;-) it simply ridiculus) or other amenities present in register 2

do not mangle my words please. it is not that things are ridiculus on vdp. the only ridiculus thing is sustain that there is the page abstraction concept on vdp basing on the workings of the R#2 register when :
-even vdp designers did not designed with such a concept in mind but as a table base address regsiter.
-it does contains memory address bits, not page number. And it does work in this way because designers WANTS a a base table address register, not a "page selector register". Nothing ridiculus, only a choice. ;-) the only thing that sounds ridiculus, is assuming that the vdp has page concept based on an address register . ;-)

when vdp designers wanted to have abstraction they simply did it as said for vdp command coordinates, but for R#2 this is not the case.

As for me, I would say that the VDP is a mix. There is both a page concept for some things and not at all for others. It looks like several teams worked on it and each added their concept by tinkering. I think this is the raison of its relative slowness that's even why v9978 couldn't see the light of day in time. By the way, v9938 was also released late. According to Nishi, it is this VDP which should have been in the MSX1. It seems that there was a lot of confusion during development. Perhaps disagreements between designers.

R#2 is only an address base pointer in bitmap modes if you ignore how it works in G6 and G7. Look at this:

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
G4,G5 | 0 |A16|A15| 1 | 1 | 1 | 1 | 1 |
      +---+---+---+---+---+---+---+---+
G6,G7 | 0 | 0 |A16| 1 | 1 | 1 | 1 | 1 |
      +---+---+---+---+---+---+---+---+

Why did A16 move? Because bits 5 and 6, in that order, actually refer to the visible page. Bit 5 is page number's bit 0, while bit 6 is page number's bit 1. Of course bit 6 goes unused in modes G6 and G7 because there's not enough VRAM. Naturally this maps to real addressess in the VRAM, and because of this Yamaha says A16 moved... Which, to me, indicates the address is being abstracted, not the visible page.

I may be mistaken, though. I agree this discussion is mostly academical, but it may give us a glimpse into Yamaha's engineers' mindset at the time the VDP was being created.

Yes, it is an "abstraction" (or whatever you want to call it). I don't like the name, because "hardware abstraction" is something that SOFTWARE DO to hide the intricacies of HARDWARE (or multiple hardware), but that is not what you are talking about. For you, it's whether some concept is (and only if it is) shoehorned into registers in its purest form (which is very naïve and lacks imagination).

Also, being valid on all screen modes is not a prerequisite of hardware specifications (that was the name I was using), only in your weird and contrived concept of "abstraction". Here is another example that contradicts your premise:

• A name table is an "abstraction" of a typographical element.
• Name tables don't exist in all graphics modes (bitmap modes don't have them);
• So, according to YOU, since a name table don't exist in all graphics mode, they are not "abstractions";

Name tables don't exist, except when they do. Anyway, it's all a figment of your imagination.