Screen 4 - vram usage | MSX Resource Center (Page 8/11)

Enlighted (6436)

28-11-2022, 08:58

pizzapower wrote:

It cannot be all of those things. R#3 defines colour table. R#4 defines pattern table. I find it arbitrary that you will go through the length of redefining the meaning of R#2 to be something vague (which is not something that technical specifications should be), but will not accept that pages are a real concept presented on the new screen modes.

It's not something vague at all. R#2 keeps the same function. It's just the color table that become useless and paterns that no longer exist in bitmap modes. As a result, yes, you can consider the table as a page but that remains arbitrary. As Grauw says, it's just a matter of semantics. I'm not saying it's stupid to do it or not, unlike you.

Par PingPong

Enlighted (4155)

28-11-2022, 11:30

gdx wrote:

pizzapower wrote:

It cannot be all of those things. R#3 defines colour table. R#4 defines pattern table. I find it arbitrary that you will go through the length of redefining the meaning of R#2 to be something vague (which is not something that technical specifications should be), but will not accept that pages are a real concept presented on the new screen modes.

It's not something vague at all. R#2 keeps the same function. It's just the color table that become useless and paterns that no longer exist in bitmap modes. As a result, yes, you can consider the table as a page but that remains arbitrary. As Grauw says, it's just a matter of semantics. I'm not saying it's stupid to do it or not, unlike you.

fully agree. It's only semantics. Perhaps worstened by the usage of term "name table"

Par pizzapower

Master (172)

28-11-2022, 15:26

gdx wrote:

pizzapower wrote:

It cannot be all of those things. R#3 defines colour table. R#4 defines pattern table. I find it arbitrary that you will go through the length of redefining the meaning of R#2 to be something vague (which is not something that technical specifications should be), but will not accept that pages are a real concept presented on the new screen modes.

It's not something vague at all. R#2 keeps the same function.

Which is...? Describe it to me as a technical guide would. And please include the bitmap modes.

Quote:

It's just the color table that become useless and paterns that no longer exist in bitmap modes. As a result, yes, you can consider the table as a page but that remains arbitrary. As Grauw says, it's just a matter of semantics. I'm not saying it's stupid to do it or not, unlike you.

What I said is stupid is the mental gymnastics one has to do and still call it a name table register the way I did back there (a name table register for something that is not a name table). It's now a page register, but it reuses an old register because it fits and extends the previous configuration. You could say it's actually "retconning" the meaning of the register and making it broader: at a higher level interpretation, it has always been a page register, since a name table is the actual thing you see on the screen in SCREEN2/4. On bitmap modes, the page register points to the framebuffer itself.

Par PingPong

Enlighted (4155)

28-11-2022, 15:36

pizzapower wrote:

It's now a page register, but it reuses an old register because it fits and extends the previous configuration. You could say it's actually "retconning" the meaning of the register and making it broader: at a higher level interpretation, it has always been a page register, since a name table is the actual thing you see on the screen in SCREEN2/4. On bitmap modes, the page register points to the framebuffer itself.

No, it's not a page register at all. If it was and, as you say, have a different meaning it should have two charateristics to *effectively* represent a page concept:
- The page number should be written directly to it without any mangling of less significant bits. (so page 0,1,2,3)
- The page number should have been agnostic (like the register holding Y coordinate in case of logical commands) regardless of screen mode.
(From an electronic point of view doing these things should had a very moderate impact in terms of complexity and transistor count, so easily feasible)

What is it really? A mangled /messed address register, specifying the start of display area that is messed up in the most quick and dirty way to allow R#23 mechanics to work correctly in conjunction with R#2 settings. But the nature of the register is clearly and address register.
About the wrong name i agree, it is not an ideal name (nametable) even of pattern modes, worst in bitmap ones.
I think they choosed this register because "is the first" thing the vdp do when it does build a scanline: it look at base address specified on R#2 and fetching the byte.

Par JohnHassink

Ambassador (5684)

28-11-2022, 17:29

PingPong wrote:

No one is perfect ;-) ;-) ;-) ;-) ;-) ;-) ;-)

Haha, I know. To be sure, I was not making fun of you or anyone here. I truly wish to have had better understanding of Assembly and the internal workings of things like the VDP.

Par gdx

Enlighted (6436)

29-11-2022, 01:29

pizzapower wrote:

Which is...? Describe it to me as a technical guide would. And please include the bitmap modes.

It's already done.
https://www.msx.org/wiki/VDP_Table_Base_Address_Registers
https://www.msx.org/wiki/VRAM_Maps
It's still incomplete because I didn't take the time to do it, but the main thing is there.

Par pizzapower

Master (172)

29-11-2022, 13:18

gdx wrote:

pizzapower wrote:

Which is...? Describe it to me as a technical guide would. And please include the bitmap modes.

It's already done.
https://www.msx.org/wiki/VDP_Table_Base_Address_Registers
https://www.msx.org/wiki/VRAM_Maps
It's still incomplete because I didn't take the time to do it, but the main thing is there.

The technical guide does a better job at this point specifically. This serves as quick reference, if that is what you are aiming for, but I think it's a wasted opportunity. What a pity. 🤷

Par gdx

Enlighted (6436)

29-11-2022, 13:51

You say that because it is not explained the way you want. I don't think you even read it. Although it's not complete yet, there is already more info in the wiki than in the doc you were talking about.

Par pizzapower

Master (172)

29-11-2022, 15:45

gdx wrote:

You say that because it is not explained the way you want. I don't think you even read it. Although it's not complete yet, there is already more info in the wiki than in the doc you were talking about.

Of course is not explained the way I want, since it doesn't even say what a page is, even though it mentions them. 🤷 Just like you, it assumes too much.

But it is succinct, which is good for a quick look. I give you that.

Par gdx

Enlighted (6436)

30-11-2022, 01:07

The "concept of page" is a false good idea to explain the operation of the VDP because it suggests that everything displayed on the screen is in the selected page when is not the case. This confuses beginners. You need to have a general knowledge of VDP to understand this "concept". By directly explaining what is (VDP uses tables), it gives a more solid base, more quickly.