Screen 4 - vram usage

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

By gdx

Enlighted (5996)

gdx's picture

27-11-2022, 14:33

pizzapower wrote:

The meaning of R#2 changed completely for the new graphics modes.

No. It is the table data format that defines the display of characters, patterns or bitmaps that changes depending the screen mode. R#2 always points to this table.

By pizzapower

Master (133)

pizzapower's picture

27-11-2022, 14:55

gdx wrote:
pizzapower wrote:

The meaning of R#2 changed completely for the new graphics modes.

No. It is the table data format that defines the display of characters, patterns or bitmaps that changes depending the screen mode. R#2 always points to this table.

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.

By PingPong

Prophet (4087)

PingPong's picture

27-11-2022, 15:04

pizzapower wrote:
gdx wrote:

Aoineko, you act like the believers who describe the bible or the quran word for word. Here it's just that the author of this doc used the term page to simplify the explanation of how it works. MSX1 has no page concept. R#2 exists since MSX1. The concept did not change thereafter. It contains an address part (because the registers are only 8 bits long). It's the same for most other registers.

The meaning of R#2 changed completely for the new graphics modes. This is how it should be explained if you fixate on this idea of R#2 stubbornly representing a single thing (namely the pattern name table, which it inherited from TMS9918):

R#2 is the name table base address. But in new modes G4 to G7:

  • in G4, the name table doesn't use byte-to-tile mapping, but one byte to two points mapping.
  • in G5, the name table doesn't use byte-to-tile mapping, but one byte to four points mapping.
  • in G7, the name table doesn't use byte-to-tile mapping, but one byte to one point mapping.
  • colours are not separated in a different table, they are there in the name table too.
  • patterns are not separated in a different table, they are there in the name table too.
  • It also defines the beginning of a visible page.

OK, a lot of assertions here are obviously true/right no one had doubt about this.

Quote:

This would be unnecessarily confusing and stupid.

What is incorrect is that Yamaha engineers mangled the R#2 register to work only at fixed steps.If it worked like in TMS way one could have used to scroll at 1K steps the entire screen but the visible part of the next screen would have been visible when scrolling in this way (using R#2) instead of rolling up, which was the desired result. Otherwise a TMS way without R23 would have been unuseful, because you had the ability to scroll a page a 1K steps showing the contents of the next page, which was not desiderable.

So Yamaha engineers fixed the R#2 base address by "raping" its own meaning (the base address ptr) fixing the less significant bits and merging those bits with the content of bits in R#23 to get the address of the first byte of the visible screen area.
They patched the R#2 in the most quick and dirty way they needed to get the trick of having the ability of vertical scroll register.
They were required to do in this way because if they would have used all the R2 bits one could have used to move the beginning of screen data at 1K steps which combined with R23 values would have got to messy and unexpected effects.
(Imagine what you could get if R2 begin area would have moved down of 2K and R23 was set to 5). What should have been showed at bottom of screen ? ;-)

But it does not change at all the fact that R#2 is not an abstraction of page concept because YOU NEED TO WRITE different values in this register based on screen mode which is against the concept of abstraction (hiding details with a more logical approach to a page concept).

In others scenarios, like x-Y abstraction on logical commands they did the correct thing. For example if you want to turn a pixel at specified coordinate to a specific color (say color 1) YOU WRITE the same x,y, color values regardless of screen mode (and this is a true abstraction).

The R#2 mangling is instead a mess required to get vertical hw scroll which rolling from the beginning of screen that otherwise wirh only R2 was impossible.

By PingPong

Prophet (4087)

PingPong's picture

27-11-2022, 15:22

Pratically the address of firs byte of screen is obtained by or-ing the most significant bits of R2 (mangled in this way) with the contents of R23 (shifted to the left by 1 in G6/G7 modes because of 256 bytes pixels x scanline instead of 128.
Something like this (not entirely correct but give the picture):
address = ((R23 << (G7_or G8) && 255 ? 8 : 7) ) || (R#2 higher bits).

Please note another interesting thing. R23 means start of scanline, and here there is another example of good abstraction, proved by the fact that you write THE SAME VALUE on this register regardless of which screen mode is selected, no matter if it was on 128 bytes x scanline or 256. More over this also work AFAIK EVEN on pattern modes and multicolor MSX1 mode ! (I think it does not work as expected on text mode, but not sure)

Just a curiosity: which is the behaviour you get if you do set at arbitrary values the less significant bits of R#2 instead of leaving them at recommended values as docs tell you to do? Expecially when you also alter R23 from its default value of 0 ?

By PingPong

Prophet (4087)

PingPong's picture

27-11-2022, 15:44

Quote:
pizzapower wrote:
gdx wrote:
pizzapower wrote:

The meaning of R#2 changed completely for the new graphics modes.

No. It is the table data format that defines the display of characters, patterns or bitmaps that changes depending the screen mode. R#2 always points to this table.

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 p33ages are a real concept presented on the new screen modes.

the page concepts exists, obviously as proved by SETPAGE basic command. What you fail to understand is *THAT* page concept DOES NOT EXIST at hw level in vdp electronics at least for R#2 things, It is only a mangled usage of R#2 to get things working but the page concept is unknown to R2 only known to the programmer. Even in logical commands there is no real page concept at vdp level, because the vdp itself see its vram as a screen made up of X by 1024 pixels in G4/G5 modes and as X by 512 pixels in G6/G7 modes!
It's the MSX BASIC that when you do a SET PAGE 0,1 knows that a pset (0, 100) command go to be specified as 256+100 for y value.
the vdp only knows when it should begin to display the screen area given by a combination of mangled R#2 value with R23 value, so an address.

You can argue that Y=256 means Page 1 and this is correct: BUT IT IS A CONCEPT THAT YOU KNOW, not THE VDP ITSELF.
Different would be if the VDP had a "Working Page" register and command coordinates falls always in the 0-255 range. this is a page concept at VDP level.!

By JohnHassink

Ambassador (5645)

JohnHassink's picture

27-11-2022, 15:40

Wow, you guys are still going. Big smile
I love that I can go in BASIC like

SET PAGE 0,1
COPY (0,0) - (15,15),1 TO (32,32),0,TPSET

And that kind of things. Smile
Games like Aleste 2 make awesome use of it.
That it what pages mean to me, abstractions or not.
And now I will shut up again. Wink

By PingPong

Prophet (4087)

PingPong's picture

27-11-2022, 15:42

Glad you enjoy with basic vdp commands ;-)

By PingPong

Prophet (4087)

PingPong's picture

27-11-2022, 15:54

gdx wrote:
pizzapower wrote:

The meaning of R#2 changed completely for the new graphics modes.

No. It is the table data format that defines the display of characters, patterns or bitmaps that changes depending the screen mode. R#2 always points to this table.

Yes.
the content of R#2 register defines only a start address. What to do in terms of interpreting bytes data at this address depends on screen mode you selected.
In bitmap modes those bytes are the pixel informations while in pattern mode those bytes specify a kind of ptr to real pixel information and there is also (because it is needed for color information) the base color table register.

however, the nametable term sounds confusing when talking about bitmap modes.

By JohnHassink

Ambassador (5645)

JohnHassink's picture

27-11-2022, 17:34

PingPong wrote:

Glad you enjoy with basic vdp commands ;-)

If I would understand it on the level that you guys do, I would have made some cool games. Smile Unfortunately, I am not so smart in these kind of things.

By PingPong

Prophet (4087)

PingPong's picture

27-11-2022, 20:07

JohnHassink wrote:
PingPong wrote:

Glad you enjoy with basic vdp commands ;-)

If I would understand it on the level that you guys do, I would have made some cool games. Smile Unfortunately, I am not so smart in these kind of things.

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

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