Screen 4 - vram usage

Page 2/11
1 | | 3 | 4 | 5 | 6 | 7

By Frederik Dumarey

Supporter (10)

Frederik Dumarey's picture

19-11-2022, 21:35

Hello PingPong,

Great, thanks for sharing so much inside info. Will puzzle your information out, and try to make a working example in Fusion-C Smile2
Once I have an example, I'll post it here!

Thanks again!
Fred.

By pizzapower

Master (134)

pizzapower's picture

20-11-2022, 07:45

PingPong wrote:
aoineko wrote:

On the V9938, the notion of page is not abstract, it is a hardware specification used for automatic page switching or interlaced display.

It is not. instead the same concepts should have been applied even on screen 4.

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.

PingPong wrote:

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.

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.

PingPong wrote:

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.

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

By Parn

Paladin (815)

Parn's picture

20-11-2022, 10:53

It's useful to keep in mind that, according to the V9938 manual, R#2 works differently in the bitmap modes. In G4 and G5 modes, bits A15 and A16 set the visible page, while from G6 mode onwards only bit A16 is used for that purpose, and it's actually the 6th bit instead of the 7th. All other R#2 bits go unused, so you can't specify the beginning of the table arbitrarily. Also, many of the TMS modes also have their own restrictions in how R#2 can be used.

By Sandy Brand

Champion (295)

Sandy Brand's picture

20-11-2022, 12:23

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.

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 13:03

It is not. To have a page concept at a VDP level there MUST BE a register saying what page is visible in every screen mode, and the vdp should take care of "details" of address management in each screen mode.
To be more clear:
writing a value to this hypotetical register would mean that the vdp pattern table (for example) will be addressed value*32768 in screen 5 for example and value*65536 in screen 7/8 or value*16384 in screen 2/3/4 and so on.
This is not the case as the vdp only has register bits.
It is an our abstraction that gives the "illusion" of a page concept. From the VDP point of view there are only address bits.
This is a different concept, for example for interleaved memory access. In this case, effectively there is a "logical" view of memory consisting of contigous addresses (from the z80 or developer point of view), but phisycally they are arranged in a diffent way.

Another example is the sprite pattern n. on sat: again it is not a real sprite number. it is only a bunch of bits used to compute the address from which to fetch sprite pattern data. If it was a *REAL* pattern number there was no need to multiply *4 the value of sprite pattern n. in SAT table when switching from 8x8 to 16x16.
Instead we need to multiply this value by four because when using 16x16 sprites the vdp is not managing the difference, it only compute the address specified in sprite pattern no without taking in account that a 16x16 sprite require four time the bytes than 8x8 to define its shape.

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 13:11

Parn wrote:

It's useful to keep in mind that, according to the V9938 manual, R#2 works differently in the bitmap modes. In G4 and G5 modes, bits A15 and A16 set the visible page, while from G6 mode onwards only bit A16 is used for that purpose, and it's actually the 6th bit instead of the 7th. All other R#2 bits go unused, so you can't specify the beginning of the table arbitrarily. Also, many of the TMS modes also have their own restrictions in how R#2 can be used.

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.

By Sandy Brand

Champion (295)

Sandy Brand's picture

20-11-2022, 13:28

But a lot of hardware back in the days (and probably today?) was designed with a lot of pragmatism and heavy focus on cost reduction. On top of that, hardware designers had to keep things (pin) compatible with older machines and thus you have a lot of bad design at the border where hardware and software interact, with lots of different functionality crammed into a couple of access registers where it is not explicitly clear if 'pages' as a concept exist or not.

If your definition of 'pages' is that there is a clean register representation for it, then you could maybe argue it actually is there, because the command engine has separate registers for the high byte of Y coordinates which correspond directly to 'pages'? Smile

By Frederik Dumarey

Supporter (10)

Frederik Dumarey's picture

20-11-2022, 13:50

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.

Smile2 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) Question

By pizzapower

Master (134)

pizzapower's picture

20-11-2022, 14:45

@PingPong what do you call register R#2 technically? What is its function regarding all graphics modes for both bitmap modes and tile modes? I was going to address your comment about a page register for all screen modes, but I think Sandy Brand did a good job already.

Here. Yamaha engineers call them "pages" (page 55 of V9938 Technical Data Book). Go fight them because I'm done here.

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 17:38

"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

Page 2/11
1 | | 3 | 4 | 5 | 6 | 7