Small inconsistency with 9938 VDP timings...

Page 3/4
1 | 2 | | 4

By PingPong

Prophet (3339)

PingPong's picture

02-08-2019, 14:17

Not really.
Pattern mode involve to access 96 bytes x scan line. (32 pat 32 col 32 name tables screen 5 is most demanding. It need 128 bytes x scanline
This also the reason Karl guttag told that a full bitmap mode was not possible on tms because of memory bandwith
So he created sc2 pattern mode as a tradeoff between memory bandwidth and full color bitmap

By Grauw

Ascended (8200)

Grauw's picture

02-08-2019, 15:03

Actually screen 0 is most demanding (surprise). I ran into this during Synthesix development.

The access slots in screen 4 and screen 5 are equally far apart, as you can see in the chart, so there’s not much of a difference in terms of access speed.

The reason for this is that screen 5 can benefit from burst mode access because the data is sequential while screen 4 tables are random access. As you can see RAS is only set once for every group of 4 bytes, it can fetch four in the same amount of time that screen 4 can fetch three. So even though it needs to fetch 33% more bytes it performs the same.

See the chart and the explanation in the article, "Page mode reads (burst read)" section.

By PingPong

Prophet (3339)

PingPong's picture

02-08-2019, 16:50

I know but my considerations were only on the amount of data read.
V9938 use bursts and reduce time. But data moved from the point of view of vram are greater on sc5

By shram86

Expert (88)

shram86's picture

02-08-2019, 19:11

It seems I'm confused again, but my tests were done on openMSX and not on hardware (I just saw no glitches so I assumed was okay).

Grauw you say vblank matters now - the articles you link don't mention blank interval at all. Are those timings only for outside of vblank?

I disabled vblank interrupts when testing this on hardware and only called the screen refresh when one loop was done. Does this mean the VDP will still process a video frame even with vblank irq off? If so, there is a small window indeed to perform unlimited vram access.

Please clarify, and I will test further on hardware later.

By Grauw

Ascended (8200)

Grauw's picture

02-08-2019, 19:34

If you’re looking at the chart, the top row marked “screen off” refers to blanking. As you can see there apart from some RAM refresh and dummy reads, all access slots are not in use by the VDP and available to the CPU and VDP commands.

Whether interrupts are enabled doesn’t matter, because the VDP is still drawing and using access slots to read from VRAM. To stop the VDP from accessing VRAM, you must blank the screen by changing the BL bit in r#1 to 0.

The VDP has two phases, example for screen 5 @ 60 Hz:

  1. Active display (212 lines)
  2. Blanking (50 “lines”)

In the blanking phase it just draws the background colour (top and bottom border), and does not access VRAM. The vertical blanking interrupt occurs at exactly the moment that it goes from phase 1 to phase 2. From then on you have 3.18 ms (11400 CPU cycles) to access the VRAM at full speed before active display starts again.

Please note that it is really best to just always add sufficient waits to your VRAM access for active display. Taking advantage of the increased VRAM access bandwidth during blanking requires full awareness of the execution timing and synchronization with the VDP to be 100% sure you always finish before active display resumes. If you do it wrong the penalty is graphics corruption and incompatibility. It is generally not worth the hassle. So adding the NOPs is the correct solution, I think.

By shram86

Expert (88)

shram86's picture

02-08-2019, 19:49

Aha, thats what I was presuming given the behavior but didn't want to be wrong (oops!) . Thanks. Good to know that screen off is the same as vblank for access waits. Though I wish there was a way to "freeze" the vdp/video like some systems Smile

By DarkSchneider

Paladin (819)

DarkSchneider's picture

02-08-2019, 19:55

The VDP needs more power when rendering more. When out-of-visible is equal to disabled, so it is completely free. More to render, more required, that's why sprite on/off matters. The combo tiles + sprites is the top (ignoring SC0). At VBLANK, and until the 1st line to render again (usually line 0 at top), it renders nothing, so availability is full. And tt VBLANK is equivalent to disable screen.

In other words, what @Grauw was refering when talking about vblank was not the interrupt itself, but the zone starting from bottom border to the top border in which the VDP draws nothing. Notice that the drawing is made by scanline (one line after another) in cycle, from top to bottom, and then top again.

Edit: a bit late Tongue

By PingPong

Prophet (3339)

PingPong's picture

02-08-2019, 20:23

OK let's explain a bit more.
The total amount of time the vdp need before a write or read could be done can be seen as the sum of two values
A) time needed to understand what you are asking. This delay starts after the second out and is fixed. It does not depend on screen on or off nor sprites
B) time needed to wait for an access slot and use this to perform the i/o. This depends on screen sprites etc.

Now if you perform the vdp write the (A) is somewhat not noticed by you because you write then wait a sufficient amount of time to another i/o operation. The byte you write get buffered and later processed

BY CONTRAST WHEN You perform a read, if you immediately read Port, (A) + (B) was not expired so you get garbage
However after a read is performed, the vdp immediately fetch in the next byte so practically only time (b) apply

Just remember (A) always should be considered while (B) is the fraction of time that in vblank we said to be 0 (no speed limit)
Of course this time is not really 0! But the cpu cannot overrun the vdp so for us there is no limit

By GhostwriterP

Champion (507)

GhostwriterP's picture

04-08-2019, 10:38

shram86 wrote:

Though I wish there was a way to "freeze" the vdp/video like some systems Smile

Double buffering with the name table would achieve something similar right?

By shram86

Expert (88)

shram86's picture

04-08-2019, 14:52

Sort of... That might stop the tearing but it would probably be a lot slower. I'll have to think about it. Smile

Page 3/4
1 | 2 | | 4