Screen 4 - vram usage

There is, you can separately specify name / pattern / color table addresses in the full 128K range, which works exactly the same as the bitmap mode pages do.

One space wasting but cool application is to use 8 pages of patterns for pattern animations, so you can have 8-step animation sequences across a large group of tiles which only take a few VDP register writes updating the pattern and colour table to animate.

Combine it with name table updates as well and you could also have longer animation sequences at still relatively little CPU cost, since you only need to write the name table once every 8 frames.

Without taking advantage of the copious amounts of VRAM like this, you would have to either rewrite patterns + pattern colours every frame where CPU bandwidth is limiting, or pre-define the animation steps as separate patterns which reduces the pattern count available.

Hi, the page concept used on screen 5 and upper screen modes in mainly a msxbasic abstraction. From the point of view of VDP it does mean only different values on vdp registers used to set the base address of vdp tables. So you can have pages even on screen 4 mode, by writing proper values on vdp registers.

For high speed commands it does depend. they (without trickery) do not work on v9938 and screen 4. they work (if enabled) on v9958 in any screen mode like in screen 8 mode.

It is not. instead the same concepts should have been applied even on screen 4. The vdp does not have a page register to be setup, it has only address registers. when you use setpage what is happening is that registers are updated according to the setpage you used. If you are referring to some special feature like page interlacing or swapping is is only a bit that is used in conjunction with the address registers to get the correct display address.

By the way the set page also define the "working page", the page where commands work, and again a MSX BASIC thing. Effectively what is happening is telling the BIOS commands to work at different addresses (by changing the Y coordinate), if the Vdp had a page concept the command register should have a a way to specify the page . instead it only have a x,y value or address register. No registers holding the page.

There is no need to play with words.
For the VDP the vram is laid out as a big screen of 256 (or 512) x (512/1024) pixels.
If you were right the vdp register they would have contained the page indication in the command or address registers.

1) HMMM (and every other vdp command) does not work on pattern modes.
2)you can vpoke the entire 17 bit area (128K), but you need to understand how things works because of compatibility with tms vdp.
The TMS vdp could only manage 16K of ram so you needed only 14 bits of address to manage. when you do a vpoke or vpeek operation you need to do this in two steps:
a) setup the vram ptr
b) output/input a byte

details of what is done in pratice with only 16K of addressing (the TMS old way):
a) set vram ptr.
output a byte to a port number #1, you need to write the low byte of address you need to vpoke or vpeek. in 'c'
output the remaining 6 bit of address to the same port bitwise oring this value if you need to perform a write operation, leaving unchanged for a read operation

int address = .....
outp (_PORT1_, (BYTE)address & 255);
outp (_PORT1_, (BYTE)(address & 63) | 64); // | because i need to write a value

now the (b) step, write or read the data byte
byte valuetopoke = .....
outp(_PORT2_, valuetopoke);

this is what happens on a TMS vdp.
However , because the V9938 had 17 bits (three bits more ) for the addressing, those extra bits are stored in an extra register (i do not remember the number, you can find this on V9938 documentations). Just because this register is like any other register you write this in the same way as other register, with the extra 3 bits to allow a 17 bit addressing.

the sequence to update a vdp register is as follow:

outp(_PORT1_, value of register you need to write);
outp(_PORT1_, 128 | number of register you need to write).

That said, the complete 17 bit addressing would be done in two steps:

a) set the extra bits registers with the bank of 16 K you need to write to:
int bank = 2; // write to third bank of 16 K value that is from address 32768 decimal.

outp(_PORT1_, bank);
outp(_PORT1_, | 128); // tell the vdp you need to write the register number ... , the 128 is bit wise or-ed to signal the vdp YOU WANT to WRITE an internal register not TO SET the VRAM PTR (!)

b) Set the usual 14 bits of a 16 VRAM address:

int writeflag = 1; // leave 0 for a read operation 1 means you want to write.

outp(_PORT1_, address & 255);
outp(_PORT1_, ((address >> 8) & 63) | writeflag);

Now you are ready to output the byte value.
outp (_PORT2_, bytevalue);

As you see, the vram access operation is kinda slow and complex, i remember there is a BIOS call that, given HL containing the 16 bit address and A containing the 17 bit could setup the VRAM Ptr as you need.

Just remember two things:
a) after you setup the vram ptr, next write operations or read operations automatically increment it, so if you are reading or writing consecutive block of bytes no need to execute another set vram ptr operation. Basically if you setup the VRAM ptr to 0x0002 and you output a byte this value is stored at 0x0002 and next bytes you output will go to 0x0003, 0x0004 etc. the same apply on read consecutive bytes.

b) there is a wrap around feature on the vram ptr: when the address ptr goes after the 16K address highest value, this wraps to 0 in all screen modes < GRAPHIC3. On GRAPHIC3 and higher modes the wrap arount occours (obviously) after you reached 0x1FFFF (the end of 128K)

Last thing: _PORT1_ is 0x99 _PORT2_ is 0x98 on almost all msx systems