Strange VRAM behaviour with SCREEN8

Paragon (1489)

29-06-2018, 17:42

Hello,

Someone in MSXVillage pointed to me a strange behaviour of the VRAM in SCREEN8 when using BASIC, in BlueMSX with a "MSX2 french" machine. If you do this program :

10 SCREEN8
20 FOR I=0TO255:VPOKEI,I:NEXTI
30 GOTO30

or this one :

10 SCREEN8
20 FOR I=0TO255:PSET(I,0),I:NEXTI
30 GOTO30

And if you pause BlueMSX and view the VRAM, you'll find that all even values are stored in page 0 (starting at $0000 : 0,2,4,6, ...), and all odd values are stored in page 1 (starting at $10000 : 1,3,5,7, ...). Which is absolutely not what the MSX2 hardware documentation says : every value should be stored in page 0, starting at $0000 (see below). Besides, it's completly illogical, too.

I've not checked, but the guy says that the SCREEN8 command in BASIC enable the bit 3 in R#8, which specifies a 64K VRAM. So it could be a mirroring effect of some kind, although I do not understand why ...

Am I missing Something ????

|		      Pattern name table
|
|   MSB    7	 6     5     4	   3	 2     1     0	  LSB
|	-------------------------------------------------
+---> 0 |     :     :	  :   (0,0)   :     :	  :	|
	-------------------------------------------------
      1 |     :     :	  :   (1,0)   :     :	  :	|
	-------------------------------------------------
      . |						|
      .
      . |						|
	-------------------------------------------------
	|   Green level   |    Red level    | Blue level|
	-------------------------------------------------
      . |						|
      .
      . |						|
	-------------------------------------------------
    255 |     :     :	  :  (255,0)  :     :	  :	|
	-------------------------------------------------
    256 |     :     :	  :   (0,1)   :     :	  :	|
	-------------------------------------------------
      . |						|
      .
      . |						|
	-------------------------------------------------
  54270 |     :     :	  : (254,211) :     :	  :	|
	-------------------------------------------------
  54271 |     :     :	  : (255,211) :     :	  :	|
	-------------------------------------------------

   Expression 4.4  The expression for accessing to the dot
		   at (X,Y) coordinate

		 --------------------------------------
		 |  ADR = X + Y * 256 + base address  |
		 --------------------------------------

By jltursan

Prophet (2619)

29-06-2018, 18:54

Isn't it related to the way VRAM must be accessed (bank interleaving) when in "heavy" modes like SC8?. It remembers me an old thread: 192KB VRAM HMMV routine

By Grauw

Ascended (10565)

29-06-2018, 19:25

In screen 7 and 8, the VDP needs more memory bandwidth than the VRAM chips can give. So it uses a trick, accessing the two halves of VRAM in parallel, doubling the bandwidth. That’s also why screen 7 and 8 don’t work in MSXes with just 64K VRAM (luckily that’s rare).

Therefore when accessing the VRAM in screen modes up to 6, it’s accessed linearly, but in screen 7 and 8 the top and bottom half are interleaved. Normally it’s transparent to the user, but if you load graphics in the one screen mode and then switch to the other, it can be noticed.

By ARTRAG

Enlighted (6832)

29-06-2018, 20:05

How sad that they have decided to not interleave the chips also in screen 5 and lower.
This would have doubled the bandwidth for vdp commands and i/o at the 'cost' of avoiding msx2's with 64kb of vram

By Metalion

Paragon (1489)

30-06-2018, 10:40

Allright, but that does not explain why the documentation says otherwise.
Furthermore, it is not transparent to the user.

By gdx

Enlighted (5360)

30-06-2018, 13:06

I think the documentation does not explain it because this must be obvious to an expert by seeing on how the RAMs are connected.

By Grauw

Ascended (10565)

30-06-2018, 13:33

Why do you say the documentation says otherwise? The physical mapping of the VRAM doesn't matter much, the logical mapping is still linear as the manual describes, and it should be transparent unless you access the VRAM between screen modes. Not saying it wouldn't have been worth an explicit mention, but the documentation does not contradict it...

By Metalion

Paragon (1489)

30-06-2018, 14:26

While pausing BlueMSX, I'm not between screen modes ... I'm actually visualizing the VRAM as it is filled with data. And what I see does not match the documentation : PSET (1,0), 1 should set the value 1 at address $0001, and what I'm seeing is the value 1 set at address $10000.

How is that transparent to the user ????

By wouter_

Champion (481)

30-06-2018, 14:32

ARTRAG wrote:

Unfortunately it doesn't work like that. Interleaving RAM banks only improves bandwidth for burst accesses (that is multiple memory reads/writes _immediately_ after each other in time to consecutive memory addresses). The VDP commands, even the high-speed block commands, can't (easily) make use of this.

By Grauw

Ascended (10565)

30-06-2018, 14:57

Metalion wrote:

How is that transparent to the user ????

Isn’t that BlueMSX’s problem? That it doesn’t take the currently active logical mapping into account in the VRAM debugger, but rather always uses the physical mapping? Normally you can’t inspect the memory like this. If you do PSET (1,0),1 and then read address 0001H through port 98H, you will get back the value 1.

A similar case exists for 32K ROMs, many files are stored according to the logical mapping that you see from the point of view of the CPU, storing the data from 4000H to C000H. But if you dump the actual ROM chip you would find that it has the first and second 16K swapped, because it simplifies the logic. Since ROM files are sometimes saved according to the physical and sometimes the logical mapping, emulators have to do an informed guess which it is by detecting the AB headers and inspecting the entry point addresses. Kanji ROMs also have a very different logical mapping than their physical storage afaik.

In the end the logical mapping is what matters to the user program, and the physical way it is stored is only really a concern for hardware manufacturers and emulators.

By gdx

Enlighted (5360)

30-06-2018, 15:01

Grauw wrote:

Isn’t that BlueMSX’s problem?

Yes, it's a trick to simplify emulation. If the emulator does not do it like that. Some programs will not work normally when changing screen 5/6 to 7/8 or vice versa without vram initialization (eg. Breaker).