I'm very curious about vdp memory bandwith use in various screen modes:

We all know that the display building is done from left to right and top to bottom. The vdp should read data in order to output for every pixel the correct color.


So taking for example the pixel at (0,0)

Screen 4:
These are the steps required:
1) The vdp should read the name table to know what pattern should show, then calculate the correct address in pattern & color attribute table
2) The vdp should fetch from vram the attribute color byte
3) the vdp should fecth from vram the pattern byte
4) vdp can output the pixel color.

Now when the raster move right from one pixel, at (1,0), All informations are already fetched, because each byte can store information for an entire "stripe" of 8 pixels.

The question is: does the VDP refetch all the data as in step (1), (2), (3) ?

I'm asking this because i know the mechanics of the C64 Vic-II chip and i also know that in a similar scenario, the VIC-II does not fetch more and more what is the msx is called name table. I'm wondering if the VDP is optimized in a similar way, in order to minimize vram fetchs-

Hope this is clear, and also hoping something could give me the answer to this...

Thx. to all.

Memory bandwidth wasn't cheap in those days. So I'd be surprised if it did. Plus, applying my current vhdl knowledge to it, it's a pretty simple thing to avoid those extra reads.

There is a way to check though. Make a test screen drawing a single pattern everywhere. Then constantly keep changing the colour table. If colour changes never happen within a single pattern, then you have it pretty much confirmed.

How do the high profile MSX emulators do it? Maybe you can check those for more information, since they claim to have pixel perfect rendering.

Quote:

Memory bandwidth wasn't cheap in those days. So I'd be surprised if it did. Plus, applying my current vhdl knowledge to it, it's a pretty simple thing to avoid those extra reads. There is a way to check though. Make a test screen drawing a single pattern everywhere. Then constantly keep changing the colour table. If colour changes never happen within a single pattern, then you have it pretty much confirmed.

This can be surely be done, however i will be more sure if i can find a confirmation from a tecnical datasheet , or by watching a real thing.

Plus there is no confirmation that the msx1 vdp works in the same way the v9938/58...

Quote:

This can be surely be done, however i will be more sure if i can find a confirmation from a tecnical datasheet , ...

You mean you want actual hardware implementation details. Now that would be very nice, especially for the 1chipMSX. But as we say in the Netherlands, that you can probably whistle to!

@edwin. On emulator there is no strange behaviour, appear that vdp fetch only when needed the bytes from vram. However i have no way to test the sample program on a real msx1/2/2+. Has anyone a way? i could send a small .com or a dos1 diskimage.

Quote:

Screen 4: These are the steps required: 1) The vdp should read the name table to know what pattern should show, then calculate the correct address in pattern & color attribute table 2) The vdp should fetch from vram the attribute color byte 3) the vdp should fecth from vram the pattern byte 4) vdp can output the pixel color. Now when the raster move right from one pixel, at (1,0), All informations are already fetched, because each byte can store information for an entire "stripe" of 8 pixels. The question is: does the VDP refetch all the data as in step (1), (2), (3) ?

After steps 1,2,3 the VDP has enough info to display 8 pixels, then the steps are repeated for the next 8 pixels. And I think it will be like this for every line, which is different from the C64 or Atari because those have a small buffer to keep the bytes from the name table so step 1 can be avoided for the next scanline(s)

just my untested hypothesis

Quote:

After steps 1,2,3 the VDP has enough info to display 8 pixels, then the steps are repeated for the next 8 pixels. And I think it will be like this for every line, which is different from the C64 or Atari because those have a small buffer to keep the bytes from the name table so step 1 can be avoided for the next scanline(s) just my untested hypothesis

@DamageX: sorry i can't understand: are you saying that for 8 pixels display the vdp make 3 fetch operations (1 name table+1 color address+1 pat.table) or 3*8=24 fetch operations?

in the latter case i could understand the reason of the restricted memory bandwidth between cpu/vdp and the limited sprites/Scanline allowed!

Yes, 3 memory fetches for 8 pixels.

Doing 3 fetches for every single pixel would have been impossible with the speed of DRAM at the time. Just think, 3 bytes per pixel would be enough for 16,777,216 colors

Umh, so most probably a screen5 patternizzed mode was not possible, because required
1: nametable
4: pixels color

a total of 5 accesses for 8 pixels...

However, i'm actually not so sure that DRAM of 20 years ago could not cope with 5 accesses per pixel:
a raster scanline is 64 microseconds. If you do 5 access per 8 pixels you end up with a 64/160 accesses per scanline (excluding sprites or other sync issues). every access could be done in 400ns.

Old DRAM have <300ns access time

Quote:

Umh, so most probably a screen5 patternizzed mode was not possible, because required 1: nametable 4: pixels color

It would have been possible with the memory system of the V9938/58 by staggering memory accesses across two banks (like screen 7 and 8) to increase bandwidth. Sprites could have been improved further as well.

I am afraid it was possible indeed. Look at the Sega Master System VDP: It is a TMS9918 evolution, but with bitmap patterns and bitmap sprites too. It uses the same master clock as the original TMS9918, also.
Although, it has some limitations, due to VRAM limit (16 K), it would have been nice to see another "evolution" for MSX2: a mixture of the SMS and the V9938 (hmmm, it sounds like V9990...)

@DamageX: sprites could be in this way be 16 on scanline!
@mohai:if possible, japanese engineers made a huge mistake creating a sc4 while they could do a sc5 patternizzed mode...

Unfortunately the big limit was the specification of only 64K VRAM. Sadly there are no msx2 with only 64vram