Screen 4 - vram usage

It kinda is because you could say that the table in R#2 defines a "visible page", since it means different things on screen 2/4 (it points to the name table) vs screen 5 (doesn't even have a name table to begin with). So the only thing screens 4 and 5 have in common according to R#2 is that R#2 defines the visible 32k/64k region of memory on screen (isn't that actually the definition of a page?). The thing that actually breaks the useful illusion of pages in SCREEN 2/4 is the lack of V9938's blit commands that support the pixel format found on those screens.

The distinction between page register or address register is not very meaningful when your "address register" has only one or two valid bits (of a total of 8) and you are only allowed to change the "address" in big, mutually exclusive intervals.

I agree that a "working page" is a BASIC construct, but a "visible page" (R#2) is not.

Well, technically, the lower bits in R#2 actually do a have a function in modes G5 and up. The content of R#2 is more akin to an 'AND bitmask' that is applied on VRAM addresses. So, it allows you to 'repeat' parts of the screen automatically. The use cases of this is rather specific though.

Anyways, I agree. I don't see the discussion about page vs address register as really meaningful either.

Exactly this proves that vdp itself do not known the concept of page in every screen mode, because if it had this concept, the vdp did not require us to take in account manually of those differences, since they are relatively easy to support at hw level. the vdp does not support this automatically because vdp designers only want to manage address bits, not logical stuffs like page.

the page concept is not on V9938 more than it is on the old TMS. Effectively you can have pages even on TMS vdp (with restrictions) for example mangling the nametable address bits, emulating the page concept.

I did some research on the post of PingPong + looked into the MSX2 Technical Handbook. The "problem" with G3 mode is that there is no VDP register page setting, nor VDP commands for vram transfers (copy operations, logical or not). So you have to dive to CPU level in order to use the whole 128KB in this tile mode.

The only way to use all VRAM is to:
- set VDP register#14 with the address, bits A14 (LSB) to A16 (17-bit to go to 0x10000 until 0x1FFFF)
- OUT#99 with address bits A0 until A7
- OUT#99, with address bits A8 until A13, bit 6= 0(read) or 1(write), bit 7=0
- OUT#98 with the data to write, or INP#98 for reading the data

the OUT-instructions work for TMS VDP MSX-1 (16KB), the extra register#14 is used for the v9938 MSX-2 128KB addressing.

I'm glad I sorted this out thanks to your help.

What I will do next is make a Fusion-C extra library for Sc4 commands like:

//vdp_tiles.h
void Sc4SetAddress (unsigned int address, unsigned char page); //address is between 0x0000 and 0x3FFF, page is between 0 and 7
void Sc4SetData (unsigned char data); //will vpoke data at Sc4SetAddress location
unsigned char Sc4GetData (void); //will vpeek data at Sc4SetAddress location
void Sc4CopyRamToVram (void *ScrRamAddress, unsigned int Length); //will copy from ram to Sc4SetAddress location
void Sc4CopyVramToRam (void *DestRamAddress, unsigned int Length); //will copy from Sc4SetAddress location to ram
void Sc4CopyVramToVram (unsigned int SrcAddress, unsigned char SrcPage, unsigned int DestAddress, unisgned char DestPage, unsigned int Length); //will copy vram from 0x0000 0x3FFF page x to another location specified size

for the mass copy instructions, maybe to get a decent speed loop, I'll have to use inline assembler using OTIR and INIR instructions?

Maybe Eric will be happy to use it in an upcoming version of Fusion-C (v1.3/1.4)

"The parameters used for the msx video are all x-y coordinates, In other words THE INTERNAL COMMAND CPROCESSOR of MSX VIDEO accesses the entire area as X-Y coordinates of the display mode"
It is clear : NO PAGE concept on VDP. However YOU CAN INTERPRET those bits as pages, BUT IT IS THE DEVELOPER THAT MAKE THIS ABSTRACTION NOT THE VDP ITSELF.

This is already enforced by the fact that R#2 does not contain the logical page number instead bits A10-A16

The page concept you read about in the docs IS SIMPLY an abstraction easy to think, but does need to take into account the screen size in various modes.

Do you want a true example of abstraction in V9938? the logical VDP commands. Here is a true abstraction, baecause you tell the vdp the pixels coordinates for commands and it does convert to physical memory addresses.
This is proved by the fact that from your point of view issuing a command on Graphic mode 4-5-6-7 is not affected by the screen mode active when you issue the command: you write always the same values!
By contrast, when doing direct vram operations on "pages" you need to take into account the screen mode because each screen mode has different size. And that is not an abstraction, you need to know details about the screen mode you use.

you told that the v9938 has page concept. following the same concept i can say that even the old TMS had page concept because by mangling base register values i can have more than one page even on the TMS vdp which never mentioned nothing about pages!!! The truth is both VDPs are the same and both work by base addresses stored in registers, the page concept is only a way to see things, but only a developer abstraction