Difference between revisions of "VRAM access timing"

From MSX Game Library

(→‎Others)
(→‎VDP command (V9938/58))
 
(42 intermediate revisions by the same user not shown)
Line 18: Line 18:
 
* The selected screen mode,
 
* The selected screen mode,
 
* The activation of the screen display,
 
* The activation of the screen display,
−
* The activation of the sprite display (V9938/58),
+
* The activation of the sprite display (V9938/58).
−
* The execution of VDP commands in parallel (V9938/58).
+
He also showed that parallel execution of a VDP command (V9938/58) on the VRAM area we're trying to access can also generates failures.
  
 
== Results ==
 
== Results ==
−
Here are the revised versions of the reference table of maximum VRAM access speeds (in number of T-States) according to the screen mode and VDP generation.
+
Here are the revised versions of the reference table of maximum VRAM access speeds (in number of t-states) according to the screen mode and VDP generation.
 +
 
 +
12 t-states is the maximum speed at which VRAM can be accessed with the MSX Z80. The VDP can probably be accessed faster under certain conditions, but we can't actually test faster accesses. So a speed of ≤12 means that the maximum access time is 12 t-states or less.
  
 
In green, the revised parts.
 
In green, the revised parts.
Line 30: Line 32:
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! VDP mode  !! Screen mode       !! TMS9918 !! V9938/58
+
! VDP mode  !! BIOS mode         !! TMS9918 !! V9938/58
 
|-
 
|-
−
| Text 1    || Screen 0, Width 40 || 12      || 20
+
| Text 1    || Screen 0, Width 40 || ≤12    || 20
 
|-
 
|-
 
| Graphic 1  || Screen 1          || 29      || 15
 
| Graphic 1  || Screen 1          || 29      || 15
Line 52: Line 54:
 
| Graphic 7  || Screen 8          || --      || 15
 
| Graphic 7  || Screen 8          || --      || 15
 
|}
 
|}
 +
 +
<u>Note:</u> For MSX1, VATT results have shown that an access time of 27 t-states generates no errors and can be considered safe (tests represent over 1.6 million bytes sent in VRAM without a single error on 17 different MSX1). However, as we are not sure that we have tested all existing MSX VDPs, we have chosen to be conservative for MSXgl and keep the maximum access time at 29 t-states.
  
 
=== No screen display ===
 
=== No screen display ===
Line 57: Line 61:
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! VDP mode  !! Screen mode       !! TMS9918 !! V9938/58
+
! VDP mode  !! BIOS mode         !! TMS9918 !! V9938/58
 
|-
 
|-
−
| Text 1    || Screen 0, Width 40 || 12      ||style="background:#DFD;"| 20
+
| Text 1    || Screen 0, Width 40 || ≤12    ||style="background:#DFD;"| 20
 
|-
 
|-
−
| Graphic 1  || Screen 1          || 12      ||style="background:#DFD;"| 15
+
| Graphic 1  || Screen 1          || ≤12    ||style="background:#DFD;"| 15
 
|-
 
|-
−
| Graphic 2  || Screen 2          || 12      ||style="background:#DFD;"| 15
+
| Graphic 2  || Screen 2          || ≤12    ||style="background:#DFD;"| 15
 
|-
 
|-
−
| Multicolor || Screen 3          || 12      ||style="background:#DFD;"| 15
+
| Multicolor || Screen 3          || ≤12    ||style="background:#DFD;"| 15
 
|-
 
|-
 
| Text 2    || Screen 0, Width 80 || --      ||style="background:#DFD;"| 20
 
| Text 2    || Screen 0, Width 80 || --      ||style="background:#DFD;"| 20
Line 71: Line 75:
 
| Graphic 3  || Screen 4          || --      ||style="background:#DFD;"| 15
 
| Graphic 3  || Screen 4          || --      ||style="background:#DFD;"| 15
 
|-
 
|-
−
| Graphic 4  || Screen 5          || --      || 12
+
| Graphic 4  || Screen 5          || --      || ≤12
 
|-
 
|-
−
| Graphic 5  || Screen 6          || --      || 12
+
| Graphic 5  || Screen 6          || --      || ≤12
 
|-
 
|-
−
| Graphic 6  || Screen 7          || --      || 12
+
| Graphic 6  || Screen 7          || --      || ≤12
 
|-
 
|-
−
| Graphic 7  || Screen 8          || --      || 12
+
| Graphic 7  || Screen 8          || --      || ≤12
 
|}
 
|}
 +
 +
<u>Note</u>: Despite common thinking, disabling the screen display has no positive impact on VRAM access times for tile-based screen modes on MSX2.
  
 
=== No sprite display (V9938/58) ===
 
=== No sprite display (V9938/58) ===
Line 84: Line 90:
  
 
{| class="wikitable"
 
{| class="wikitable"
−
! VDP mode  !! Screen mode       !! TMS9918 !! V9938/58
+
! VDP mode  !! BIOS mode         !! TMS9918 !! V9938/58
 
|-
 
|-
 
| Text 1    || Screen 0, Width 40 || --      || 20
 
| Text 1    || Screen 0, Width 40 || --      || 20
Line 107: Line 113:
 
|}
 
|}
  
−
These results are yet to be confirmed (some machines may have worse cases that invalidate these results).
+
<u>Note:</u> These results are yet to be confirmed (some machines may have worse cases that invalidate these results).
 
We therefore do not recommend (for the moment) taking advantage of these better access times when sprites are disabled.
 
We therefore do not recommend (for the moment) taking advantage of these better access times when sprites are disabled.
  
 
=== VDP command (V9938/58) ===
 
=== VDP command (V9938/58) ===
−
Running VDP command don't really have impact on maximal speed of direct access to VRAM but can generate glitches. Tests have shown that this happens when the command work on the same VRAM area than the direct access do. In this case, and only in this case, direct access can failed and VRAM can be corrupted (presumably by command malfunction).
+
Running VDP command in parallel don't really have impact on maximal speed of direct access to VRAM, but can generate glitches. Tests have shown that this happens when the command work on the same VRAM area than the direct access do. In this case, and only in this case, direct access can failed and VRAM can be corrupted (presumably by command malfunction).
  
 
When you load data into VRAM it is therefore recommended that you do not run any VDP commands in parallel, or at least never on the same VRAM area.
 
When you load data into VRAM it is therefore recommended that you do not run any VDP commands in parallel, or at least never on the same VRAM area.
  
 
If you have previously started commands on this VRAM area and you are not sure if they are finished, it is recommended to use the <tt>VDP_CommandWait()</tt> function before starting direct access to that area.
 
If you have previously started commands on this VRAM area and you are not sure if they are finished, it is recommended to use the <tt>VDP_CommandWait()</tt> function before starting direct access to that area.
 +
 +
<u>Note</u>: Execution time of VDP commands is also influenced by the same context elements as VRAM direct access times: screen display, sprite display, v-blank, etc. But unlike direct access, which can fail, the only issue with VDP commands is the time they take to execute (and how to optimize code to take advantage of it). More info here: https://map.grauw.nl/articles/vdp_commands_speed.php
  
 
=== Emulation ===
 
=== Emulation ===
−
 
+
{{:VRAM access timing/Emulation}}
−
==== openMSX ====
 
−
 
 
−
==== Emulicious ====
 
−
 
 
−
==== Others ====
 
−
The following emulators do not emulate VDP access time constraints at all: fMSX, blueMSX, RuMSX and MEISEI.
 
  
 
== Annexes ==
 
== Annexes ==
Line 130: Line 132:
 
=== Testing protocol ===
 
=== Testing protocol ===
 
The VATT tool uses the following technique to validate that accessing the VRAM at a given speed is safe or not with the selected Screen mode:
 
The VATT tool uses the following technique to validate that accessing the VRAM at a given speed is safe or not with the selected Screen mode:
−
* Setup test condition (Screen mode, Screen display enable/disable, etc.).
+
* Setup test condition (Screen mode, Screen display enable/disable, Sprite enable/disable, VDP command execution, etc.).
−
* Write slowly (with 31 t-states between each write) a sequence of 256 characters which are used to initialize the VRAM.
+
* Write slowly (with 31 t-states between each write) a sequence of 256 characters which are used as reference to initialize the VRAM.
 
* Write 256 times a control character with the speed function we want to test (from a 12 to 31 t-states write interval).
 
* Write 256 times a control character with the speed function we want to test (from a 12 to 31 t-states write interval).
−
* Read slowly the 256 characters and count the number of times the control character is present.
+
* Read slowly (more than 31 t-states interval) the 256 characters and count the number of times the control character is present.
 
* Repeat these steps N times (between 1 and 128) and calculate an average, a minimum and a maximum.
 
* Repeat these steps N times (between 1 and 128) and calculate an average, a minimum and a maximum.
  
 
If the average is not 100 (displayed as "OK") it means that there was at least one access miss among all the iterations. Therefore, this access speed is not safe for the tested context.
 
If the average is not 100 (displayed as "OK") it means that there was at least one access miss among all the iterations. Therefore, this access speed is not safe for the tested context.
 +
 +
Some examples:
 +
{|
 +
| {{IMG|raw.githubusercontent.com/aoineko-fr/VATT/master/doc/benchmark/nms8250_sc1_sp1_cm0.jpg|height:200px|Philips NMS 8250}}
 +
| {{IMG|raw.githubusercontent.com/aoineko-fr/VATT/master/doc/benchmark/fsa1_rom.jpg|height:200px|Panasonic FS-A1}}
 +
|}
  
 
=== Reference machines ===
 
=== Reference machines ===
 
Result founded with VATT have been confirmed on those machines:
 
Result founded with VATT have been confirmed on those machines:
 
{| class="wikitable sortable"
 
{| class="wikitable sortable"
−
! Machine           !! BIOS        !! VDP                         !! Region !! Misc.
+
! Machine               !! BIOS        !! VDP                         !! Region !! Misc.
 +
|-
 +
| Canon V-8            || MSX1      || Texas Instruments TMS9118NL  || NTSC  ||
 +
|-
 +
| ''Canon V-20''        || MSX1      || Texas Instruments TMS9918ANL || NTSC  ||
 
|-
 
|-
−
| Casio PV-7        || MSX1       || Texas Instruments TMS9118NL || NTSC  ||  
+
| Casio MX-10          || MSX1       || Texas Instruments TMS9118NL || NTSC  ||  
 
|-
 
|-
−
| Panasonic FS-A1  || MSX2        || Yamaha V9938                || NTSC  ||  
+
| Casio MX-101          || MSX1      || Texas Instruments TMS9118NL  || NTSC  ||  
 
|-
 
|-
−
| Panasonic FS-A1FX || MSX2+       || Yamaha V9958                || NTSC  || I/O +2 t-states
+
| ''Casio PV-7''        || MSX1       || Texas Instruments TMS9118NL  || NTSC  ||  
 +
|-
 +
| Gradiente Expert GPC-1 || MSX1      || Texas Instruments TMS9128NL  || NTSC  ||
 
|-
 
|-
−
| Panasonic FS-A1GT || MSX turbo R || Yamaha V9958                || NTSC  || I/O +1 t-state
+
| Hitachi MB-H1        || MSX1      || Texas Instruments TMS9918ANL || NTSC  ||  
 
|-
 
|-
−
| Philips NMS 8245 (modded) || MSX2 || Yamaha V9958              || PAL    ||  
+
| Mitsubishi ML-8000    || MSX1      || Texas Instruments TMS9918ANL || NTSC  ||  
 
|-
 
|-
−
| Philips NMS 8250  || MSX2        || Yamaha V9938                || PAL    ||  
+
| National CF-2700      || MSX1      || Texas Instruments TMS9918A  || NTSC  ||  
 
|-
 
|-
−
| Sony HB-75P       || MSX1        || Texas Instruments TMS9929A  || PAL    ||
+
| Panasonic FS-A1       || MSX2       || Yamaha V9938                 || NTSC  ||  
−
|- 
 
−
| Sony HB-F1XD      || MSX2       || Yamaha V9938               || NTSC  ||
 
−
|- 
 
−
| Victor HC-30      || MSX1        || Yamaha YM2220              || NTSC  ||  
 
 
|-
 
|-
−
| Yamaha CX5MII    || MSX1       || Yamaha V9938               || PAL    ||  
+
| ''Panasonic FS-A1FX'' || MSX2+      || Yamaha V9958                || NTSC  || I/O +2 t-states
 +
|-
 +
| ''Panasonic FS-A1GT'' || MSX turbo R || Yamaha V9958                || NTSC  || I/O +1 t-state
 +
|-
 +
| ''Philips NMS 8245'' (modded) || MSX2 || Yamaha V9958              || PAL    ||
 +
|-
 +
| Philips NMS 8250      || MSX2      || Yamaha V9938                || PAL    ||
 +
|-
 +
| Sanyo MPC-2          || MSX1      || Toshiba T6950                || NTSC  ||
 +
|-
 +
| Sanyo MPC-3          || MSX1      || Texas Instruments TMS9118NL  || NTSC  ||
 +
|-
 +
| Sharp HB-8000 (v1.1)  || MSX1      || Texas Instruments TMS9128NL  || NTSC  ||
 +
|-
 +
| Sharp HB-8000 (v1.2)  || MSX1      || Texas Instruments TMS9128NL  || NTSC  ||
 +
|-
 +
| Sony HB-75P          || MSX1      || Texas Instruments TMS9929    || NTSC  ||
 +
|-
 +
| ''Sony HB-F1XD''      || MSX2      || Yamaha V9938                || NTSC  ||
 +
|-
 +
| ''Sony HB-F1XD''      || MSX2      || Yamaha V9938                || NTSC  ||
 +
|-
 +
| Sony HB-F500 (rev2)  || MSX2      || Yamaha V9938                || NTSC  ||
 +
|-
 +
| Toshiba HX-10DP      || MSX1      || Texas Instruments TMS9918A  || NTSC  ||
 +
|-
 +
| Toshiba HX-21        || MSX1      || Texas Instruments TMS9928A  || NTSC  ||
 +
|-
 +
| ''Victor HC-30''      || MSX1      || Yamaha YM2220                || NTSC  ||
 +
|-
 +
| ''Yamaha CX5MII''     || MSX1       || Yamaha V9938                 || PAL    ||  
 
|}
 
|}
 +
 +
 +
In italics, machines with only a partial result (test performed with an older version of VATT).
 +
 +
Database with all result can be found there: https://docs.google.com/spreadsheets/d/16uGdJ7JT1MWZ4qQLUDrGk1Wfw3w_EbaMpoS_fxeSJuI/edit?usp=sharing

Latest revision as of 08:45, 25 September 2024

As MSXGL intends to offer the best possible performance to MSX game creators, special attention has been paid to ensure the highest possible speed when accessing the VRAM. But, MSX hardware is so made that it is sometimes possible (depending on the context) to write or read too quickly in the VDP memory and thus to create data corruptions. To create the VDP module we based our VRAM access times on the information available on the net and in particular on the site MSX Assembly Page and its articles which are references in this field:

The last article gives a table of possible access times for each screen mode for each VDP generation. Thus, the VDP module of MSXgl automatically adjusts its access times to the screen modes chosen in the library configuration (msxgl_config.h) to allow the best possible access times while ensuring the proper functioning of the application even in the worst case scenario.

The problem is that in some situations, we could observe data corruption in a context where the given access times were respected. A tool was then created to verify these theoretical access times with concrete test cases: VATT (for VRAM Access Timing Tester).

The results of these tests showed that the reference data had some limitations. Notably a wrong access time for Screen Mode 3 on MSX1 (TMS9918) or an unexpected effect with screen disabling for non-bitmap modes on MSX2 (V9938/58). These results have yet to be confirmed with other tests, but they have highlighted worst-case scenarios that we need to consider.

The VATT tool highlighted that access times depend on:

  • The generation of the VDP,
  • The selected screen mode,
  • The activation of the screen display,
  • The activation of the sprite display (V9938/58).

He also showed that parallel execution of a VDP command (V9938/58) on the VRAM area we're trying to access can also generates failures.

Results

Here are the revised versions of the reference table of maximum VRAM access speeds (in number of t-states) according to the screen mode and VDP generation.

12 t-states is the maximum speed at which VRAM can be accessed with the MSX Z80. The VDP can probably be accessed faster under certain conditions, but we can't actually test faster accesses. So a speed of ≤12 means that the maximum access time is 12 t-states or less.

In green, the revised parts.

Default

The default condition is when Screen display is activated. On MSX2 or above, the Sprite display is also activated.

VDP mode BIOS mode TMS9918 V9938/58
Text 1 Screen 0, Width 40 ≤12 20
Graphic 1 Screen 1 29 15
Graphic 2 Screen 2 29 15
Multicolor Screen 3 29 15
Text 2 Screen 0, Width 80 -- 20
Graphic 3 Screen 4 -- 15
Graphic 4 Screen 5 -- 15
Graphic 5 Screen 6 -- 15
Graphic 6 Screen 7 -- 15
Graphic 7 Screen 8 -- 15

Note: For MSX1, VATT results have shown that an access time of 27 t-states generates no errors and can be considered safe (tests represent over 1.6 million bytes sent in VRAM without a single error on 17 different MSX1). However, as we are not sure that we have tested all existing MSX VDPs, we have chosen to be conservative for MSXgl and keep the maximum access time at 29 t-states.

No screen display

Maximum access speed when Screen display is disable.

VDP mode BIOS mode TMS9918 V9938/58
Text 1 Screen 0, Width 40 ≤12 20
Graphic 1 Screen 1 ≤12 15
Graphic 2 Screen 2 ≤12 15
Multicolor Screen 3 ≤12 15
Text 2 Screen 0, Width 80 -- 20
Graphic 3 Screen 4 -- 15
Graphic 4 Screen 5 -- ≤12
Graphic 5 Screen 6 -- ≤12
Graphic 6 Screen 7 -- ≤12
Graphic 7 Screen 8 -- ≤12

Note: Despite common thinking, disabling the screen display has no positive impact on VRAM access times for tile-based screen modes on MSX2.

No sprite display (V9938/58)

Maximum access speed when Screen display is enable but Sprite display is disable.

VDP mode BIOS mode TMS9918 V9938/58
Text 1 Screen 0, Width 40 -- 20
Graphic 1 Screen 1 -- 15
Graphic 2 Screen 2 -- 15
Multicolor Screen 3 -- 15
Text 2 Screen 0, Width 80 -- 20
Graphic 3 Screen 4 -- 15
Graphic 4 Screen 5 -- 14
Graphic 5 Screen 6 -- 14
Graphic 6 Screen 7 -- 14
Graphic 7 Screen 8 -- 14

Note: These results are yet to be confirmed (some machines may have worse cases that invalidate these results). We therefore do not recommend (for the moment) taking advantage of these better access times when sprites are disabled.

VDP command (V9938/58)

Running VDP command in parallel don't really have impact on maximal speed of direct access to VRAM, but can generate glitches. Tests have shown that this happens when the command work on the same VRAM area than the direct access do. In this case, and only in this case, direct access can failed and VRAM can be corrupted (presumably by command malfunction).

When you load data into VRAM it is therefore recommended that you do not run any VDP commands in parallel, or at least never on the same VRAM area.

If you have previously started commands on this VRAM area and you are not sure if they are finished, it is recommended to use the VDP_CommandWait() function before starting direct access to that area.

Note: Execution time of VDP commands is also influenced by the same context elements as VRAM direct access times: screen display, sprite display, v-blank, etc. But unlike direct access, which can fail, the only issue with VDP commands is the time they take to execute (and how to optimize code to take advantage of it). More info here: https://map.grauw.nl/articles/vdp_commands_speed.php

Emulation

openMSX

openMSX (18.0) supports VRAM access time emulation with the following limitations:

  • In the default mode (display and sprites enable), it is a little too optimistic, i.e. within about 1~2 t-states, accesses that will work on openMSX will not work on a real machine. For example, on a Philips NMS 8250, an access with an interval of 19 t-states will work on openMSX but may fail on a real machine.
  • With display disabled, it does not emulate at all the access time limitations of the non-bitmap display modes on V9938/58. This can be a major source of error, as this limitation doesn't exists on TMS9918 and don't seem to be documented.
  • With sprites disabled, it still emulates too optimistically, sometimes with a 3 t-state gap between valid intervals in openMSX and those observed on a real machine. For example, while an access in graphics mode 1 with an interval of 12 t-states is valid in openMSX, it requires at least 15 t-states on a real machine.

Note: openMSX emulates quite faithfully write failures linked to a VDP command active on the same VRAM zone.

Emulicious

Emulicious (2023-04-22) has a limited emulation of VRAM access time:

  • On TMS9918, a limitation exists for the default mode (display enabled) but it does not correspond to the value observed on a real machine. All screen modes seem to have an access limit of 25 t-states, whereas valid intervals are supposed to be 12 t-states for Text 1 mode and 29 for the others.
  • On the other hand, with the screen off, access times are correct.
  • On V9938/58, no limitation seems to be emulated at all.

Note: A forthcoming version of Emulicious should enable more precise emulation of VDP access timing.

Others

Other emulators do not emulate VDP access timing constraints at all: fMSX (6.0), blueMSX (2.8.2), MEISEI (1.3.2), RuMSX (0.83) and WebMSX (6.0.4).

Annexes

Testing protocol

The VATT tool uses the following technique to validate that accessing the VRAM at a given speed is safe or not with the selected Screen mode:

  • Setup test condition (Screen mode, Screen display enable/disable, Sprite enable/disable, VDP command execution, etc.).
  • Write slowly (with 31 t-states between each write) a sequence of 256 characters which are used as reference to initialize the VRAM.
  • Write 256 times a control character with the speed function we want to test (from a 12 to 31 t-states write interval).
  • Read slowly (more than 31 t-states interval) the 256 characters and count the number of times the control character is present.
  • Repeat these steps N times (between 1 and 128) and calculate an average, a minimum and a maximum.

If the average is not 100 (displayed as "OK") it means that there was at least one access miss among all the iterations. Therefore, this access speed is not safe for the tested context.

Some examples:


Philips NMS 8250

Panasonic FS-A1

Reference machines

Result founded with VATT have been confirmed on those machines:

Machine BIOS VDP Region Misc.
Canon V-8 MSX1 Texas Instruments TMS9118NL NTSC
Canon V-20 MSX1 Texas Instruments TMS9918ANL NTSC
Casio MX-10 MSX1 Texas Instruments TMS9118NL NTSC
Casio MX-101 MSX1 Texas Instruments TMS9118NL NTSC
Casio PV-7 MSX1 Texas Instruments TMS9118NL NTSC
Gradiente Expert GPC-1 MSX1 Texas Instruments TMS9128NL NTSC
Hitachi MB-H1 MSX1 Texas Instruments TMS9918ANL NTSC
Mitsubishi ML-8000 MSX1 Texas Instruments TMS9918ANL NTSC
National CF-2700 MSX1 Texas Instruments TMS9918A NTSC
Panasonic FS-A1 MSX2 Yamaha V9938 NTSC
Panasonic FS-A1FX MSX2+ Yamaha V9958 NTSC I/O +2 t-states
Panasonic FS-A1GT MSX turbo R Yamaha V9958 NTSC I/O +1 t-state
Philips NMS 8245 (modded) MSX2 Yamaha V9958 PAL
Philips NMS 8250 MSX2 Yamaha V9938 PAL
Sanyo MPC-2 MSX1 Toshiba T6950 NTSC
Sanyo MPC-3 MSX1 Texas Instruments TMS9118NL NTSC
Sharp HB-8000 (v1.1) MSX1 Texas Instruments TMS9128NL NTSC
Sharp HB-8000 (v1.2) MSX1 Texas Instruments TMS9128NL NTSC
Sony HB-75P MSX1 Texas Instruments TMS9929 NTSC
Sony HB-F1XD MSX2 Yamaha V9938 NTSC
Sony HB-F1XD MSX2 Yamaha V9938 NTSC
Sony HB-F500 (rev2) MSX2 Yamaha V9938 NTSC
Toshiba HX-10DP MSX1 Texas Instruments TMS9918A NTSC
Toshiba HX-21 MSX1 Texas Instruments TMS9928A NTSC
Victor HC-30 MSX1 Yamaha YM2220 NTSC
Yamaha CX5MII MSX1 Yamaha V9938 PAL


In italics, machines with only a partial result (test performed with an older version of VATT).

Database with all result can be found there: https://docs.google.com/spreadsheets/d/16uGdJ7JT1MWZ4qQLUDrGk1Wfw3w_EbaMpoS_fxeSJuI/edit?usp=sharing

Retrieved from "https://aoineko.org/msxgl/index.php?title=VRAM_access_timing&oldid=2799"