VRAM access timing

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:

• V9938 VRAM timings,
• V9938 VRAM timings, part II,
• VRAM access timing in VDP programming tutorial.

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),
• The execution of VDP commands in parallel (V9938/58).

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.

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	Screen 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

No screen display

Maximum access speed when Screen display is disable.

VDP mode	Screen 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

No sprite display (V9938/58)

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

VDP mode	Screen 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

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

Emulation

Others

The following emulators do not emulate VDP access time constraints at all: fMSX, blueMSX, RuMSX and MEISEI.

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, etc.).
• Write slowly (with 31 t-states between each write) a sequence of 256 characters which are used 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 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.

Reference machines

Result founded with VATT have been confirmed on those machines:

Machine	BIOS	VDP	Region	Misc.
Casio PV-7	MSX1	Texas Instruments TMS9118NL	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
Sony HB-75P	MSX1	Texas Instruments TMS9929A	PAL
Sony HB-F1XD	MSX2	Yamaha V9938	NTSC
Victor HC-30	MSX1	Yamaha YM2220	NTSC
Yamaha CX5MII	MSX1	Yamaha V9938	PAL