Screen 4 - vram usage

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

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 17:41

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.

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 17:46

Exactly! All those behaviours prove the fact that R#2 values are *ONLY* base addresses NOT ONLY PAGES.
Otherwise, if the VDP had true page concept, all those considerations about which bits are used or not in various screen modes were not needed. With a true page concept you only need to write the page number you want to access. Not to take into account which bits are used or not in screen modes.

By aoineko

Paladin (813)

aoineko's picture

20-11-2022, 19:44

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.

By Metalion

Paragon (1617)

Metalion's picture

20-11-2022, 20:09

Guys, you're picking a fight about a small detail.
You should agree to disagree and let it rest.
Just my 2 cents.

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 20:46

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.

By pizzapower

Master (134)

pizzapower's picture

20-11-2022, 22:19

PingPong wrote:

"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.

Although pages are not used in VDP commands, address registers are also not used in VDP commands. So, by your own logic, the interpretation of the R#2 bits as address registers is also wrong. VDP commands just ignore it and use absolute pixel positions on a larger framebuffer anyway.

On the other hand, there are reasons to interpret the R#2 register as pages since it defines a rigid, non-overlapping and equally divided way of splitting the memory and selecting a single page to be visible, just like RAM pages are pushed back and forth by selecting them from slots.

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 22:21

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.

By pizzapower

Master (134)

pizzapower's picture

20-11-2022, 23:16

Nobody said that R#2 should be used this way but you. The docs don't prove your point either. Not in description nor function. I already stated the reason for considering R#2 as pages several times already and it has nothing to do with vdp commands.

PingPong wrote:

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.

Wrong. Firstly, the VDP has the concept of a visible page (since, if you change R#2, it defines what you will see on the display) and, secondly, it cannot be anything different than a page-sized region of memory in predefined memory positions. And that last rule is enforced by the VDP itself.

By PingPong

Prophet (4088)

PingPong's picture

20-11-2022, 23:46

pizzapower wrote:

Nobody said that R#2 should be used this way but you. The docs don't prove your point either. Not in description nor function. I already stated the reason for considering R#2 as pages several times already and it has nothing to do with vdp commands.

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 ? Big smile Big smile Big smile Big smile Big smile Big smile Big smile
- 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.

By aoineko

Paladin (813)

aoineko's picture

21-11-2022, 00:27

PingPong wrote:

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.

Officiel V9938 documentation by Yamaha and ASCII wrote:

Whether you like it or not, "page concept" is part of the V9938 specifications. This is not just a "msxbasic abstraction" as you claimed in the message I replied to. Feel free not to call it "pages" if you like, but you are making it unnecessarily difficult for beginners to learn and I think that's a shame.

If they want to display an interlaced image with the V9938 for example, they will need to understand the notion of "page" and hearing that it does not exist is not going to help them.

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