Screen 4 - vram usage

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

By pizzapower

Expert (113)

pizzapower's picture

21-11-2022, 01:25

PingPong wrote:

Otherwise if R#2 is the page why i cannot simply write 0,1,2,3 on it instead of a a value that is a 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

No, duh. When you use the MSX2 bitmap modes, the pages are all predefined 32k or 64k and fixed in size. And when you use the vertical scroll register you can see the full length of the screen page. That is not just an abstraction: the visible page has a starting and a finishing address that is confined within the limits of a memory page in VRAM.

And there is nothing wrong in reusing old V9918 registers and extend them to include your own uses if it doesn't hurt the standard and, on top of that, saves on costs.

PingPong wrote:

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

So, because the VDP has no means of using a register directly and in the way YOU prescribe, it cannot be a part of the hardware specification? That is absurd. If you don't respect the page boundaries in VRAM (for instance 0x0000-0x7ffff, 0x8000-0xffff, 0x10000-0x17fff, 0x18000-0x1ffff for screen 5) when you build your own MSX, you get a fragmented image on the screen. Since the VDP is not a brain in a vat, it must serve the purpose of rendering the screen properly for the user (and that is part of the hardware specification you know?).

But because hardware specifications means nothing to you, you should remove your keyboard and interface with your MSX via brain waves. That is OK because the Z80 holds no concept of a physical keyboard, it just needs the input ports.

By PingPong

Prophet (3997)

PingPong's picture

21-11-2022, 01:33

Quote:

No, duh. When you use the MSX2 bitmap modes, the pages are all predefined 32k or 64k and fixed in size. And when you use the vertical scroll register you can see the full length of the screen page. That is not just an abstraction: the visible page has a starting and a finishing address that is confined in the limits of a memory page in VRAM.

the fact they reused the registers by using only higher bits is only to avoid the inconsistency that would arise if they used the total n. of bit of available.
the R23 has no direct relation with page concept: it is here to allow hw scrolling and it was reasonable that it worked on a single screen page at once otherwise it is only a duplicate of R#2. Clearly.

Quote:

So, because the VDP has no means of using a register directly and in the way YOU want it to be used, it cannot be a part of the hardware specification?

First: i do not want anything. i only see what is it here. without any interpretation. the R2 register is a register.stop.
as said the requirement of using only higher bits in r2 in higher modes is only to avoid the MESS that otherwise will occour (and you described above) if you could use other less significant bits in the register. And this is another strong prove of my point of view.
If the vdp was meant with page concept in mind instead of raw addresses there would have no been no need to mask out less significant bits in bitmap modes, they could have worked as i said, with the page number instead of addresses.
And please: this is not a way I WANT vdp to work. it's the only way it could have worked in a reasonable way if the designers had wanted to have a page concept instead of raw addresses. the way it is working is reasonable only to you ;-) if see a page concept here,
when vdp designers wants an abstraction they did it correctly: as already clearly demonstrated in the case of the vdp logic commands: here the designers wanted this abstraction and they created it correctly without bit masking depending on screen mode (what kind of page abstraction is if you need to take in account the screen mode detail ;-) it simply ridiculus) or other amenities present in register 2

By pizzapower

Expert (113)

pizzapower's picture

21-11-2022, 02:01

Oh, I see, no judgements. Things are just "ridiculous" and don't work in a "reasonable way". Sorry, that's just funny. For the record, I give zero ducks what you think about the standard. That was never the point.

But, OK, guys. PingPong doesn't like the term "payj", even though that describes very well how VRAM is divided and what the page (oops, sorry!) is used for. Let's just not use it around him. I am off.

By PingPong

Prophet (3997)

PingPong's picture

21-11-2022, 06:40

do not mangle my words please. it is not that things are ridiculus on vdp. the only ridiculus thing is sustain that there is the page abstraction concept on vdp basing on the workings of the R#2 register when :
-even vdp designers did not designed with such a concept in mind but as a table base address regsiter.
-it does contains memory address bits, not page number. And it does work in this way because designers WANTS a a base table address register, not a "page selector register". Nothing ridiculus, only a choice. ;-) the only thing that sounds ridiculus, is assuming that the vdp has page concept based on an address register . ;-)

when vdp designers wanted to have abstraction they simply did it as said for vdp command coordinates, but for R#2 this is not the case.

By ro

Scribe (4819)

ro's picture

24-11-2022, 09:29

Gents, discussing these technical thingies is awesome. If we stick to bits, and not the person we make awesome content. Keep digging further.

By gdx

Enlighted (5850)

gdx's picture

24-11-2022, 11:37

As for me, I would say that the VDP is a mix. There is both a page concept for some things and not at all for others. It looks like several teams worked on it and each added their concept by tinkering. I think this is the raison of its relative slowness that's even why v9978 couldn't see the light of day in time. By the way, v9938 was also released late. According to Nishi, it is this VDP which should have been in the MSX1. It seems that there was a lot of confusion during development. Perhaps disagreements between designers.

By PingPong

Prophet (3997)

PingPong's picture

24-11-2022, 12:34

yes the vdp is a mix, for example the vdp command engine use some abstraction, it does not work with addresses leaving to you the job to calculate what address load in a register to perform for example a block fill or move operations. Instead it work on abstraction ( X,Y) coordinates a do the job of traslating them into addresses by taking in account the screen mode.

Different from R#2 that is basically an address base ptr.

By Parn

Paladin (809)

Parn's picture

25-11-2022, 14:50

R#2 is only an address base pointer in bitmap modes if you ignore how it works in G6 and G7. Look at this:

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
G4,G5 | 0 |A16|A15| 1 | 1 | 1 | 1 | 1 |
      +---+---+---+---+---+---+---+---+
G6,G7 | 0 | 0 |A16| 1 | 1 | 1 | 1 | 1 |
      +---+---+---+---+---+---+---+---+

Why did A16 move? Because bits 5 and 6, in that order, actually refer to the visible page. Bit 5 is page number's bit 0, while bit 6 is page number's bit 1. Of course bit 6 goes unused in modes G6 and G7 because there's not enough VRAM. Naturally this maps to real addressess in the VRAM, and because of this Yamaha says A16 moved... Which, to me, indicates the address is being abstracted, not the visible page.

I may be mistaken, though. I agree this discussion is mostly academical, but it may give us a glimpse into Yamaha's engineers' mindset at the time the VDP was being created.

By PingPong

Prophet (3997)

PingPong's picture

25-11-2022, 19:05

Parn wrote:

R#2 is only an address base pointer in bitmap modes if you ignore how it works in G6 and G7. Look at this:

        7   6   5   4   3   2   1   0
      +---+---+---+---+---+---+---+---+
G4,G5 | 0 |A16|A15| 1 | 1 | 1 | 1 | 1 |
      +---+---+---+---+---+---+---+---+
G6,G7 | 0 | 0 |A16| 1 | 1 | 1 | 1 | 1 |
      +---+---+---+---+---+---+---+---+

Why did A16 move? Because bits 5 and 6, in that order, actually refer to the visible page. Bit 5 is page number's bit 0, while bit 6 is page number's bit 1. Of course bit 6 goes unused in modes G6 and G7 because there's not enough VRAM. Naturally this maps to real addressess in the VRAM, and because of this Yamaha says A16 moved... Which, to me, indicates the address is being abstracted, not the visible page.

I may be mistaken, though. I agree this discussion is mostly academical, but it may give us a glimpse into Yamaha's engineers' mindset at the time the VDP was being created.

In any case the fact that i need to consider the bit layout based on screen mode confirm the fact that it is not an abstraction (otherwise the value i write on this register should be unaffected) but instead a thing that is more closer to bare metal

By pizzapower

Expert (113)

pizzapower's picture

25-11-2022, 20:33

PingPong wrote:

In any case the fact that i need to consider the bit layout based on screen mode confirm the fact that it is not an abstraction

Yes, it is an "abstraction" (or whatever you want to call it). I don't like the name, because "hardware abstraction" is something that SOFTWARE DO to hide the intricacies of HARDWARE (or multiple hardware), but that is not what you are talking about. For you, it's whether some concept is (and only if it is) shoehorned into registers in its purest form (which is very naïve and lacks imagination).

Also, being valid on all screen modes is not a prerequisite of hardware specifications (that was the name I was using), only in your weird and contrived concept of "abstraction". Here is another example that contradicts your premise:

  • A name table is an "abstraction" of a typographical element.
  • Name tables don't exist in all graphics modes (bitmap modes don't have them);
  • So, according to YOU, since a name table don't exist in all graphics mode, they are not "abstractions";

Name tables don't exist, except when they do. Anyway, it's all a figment of your imagination. oO

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