Difference between revisions of "VRAM access timing"
From MSX Game Library
(→VDP command (V9938/58)) |
|||
| Line 108: | Line 108: | ||
=== VDP command (V9938/58) === | === VDP command (V9938/58) === | ||
| − | Running VDP command have no impact on maximal speed of direct access to VRAM but can generate | + | Running VDP command have no impact on maximal speed of direct access to VRAM but can generate glitches. It occurs 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). |
== Annexe == | == Annexe == | ||
Revision as of 18:08, 26 April 2023
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 MSX Assembly Page (from MRC user Grauw) 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.
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).
Contents
Result
Default
The default condition is when Screen display is activated. On MSX2 or above, the Sprite display is 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 sprite display (V9938/58)
Maximum access speed when Sprite display is disable and Screen display is enable.
| 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 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 |
VDP command (V9938/58)
Running VDP command have no impact on maximal speed of direct access to VRAM but can generate glitches. It occurs 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).
Annexe
Reference
Result founded with VATT have been validated on those machines:
- Casio PV-7 (MSX1, TMS9918?, NTSC)
- Panasonic FS-A1 (MSX2, Yamaha V9938?, NTSC)
- Panasonic FS-A1FX (MSX2+, Yamaha V9958, NTSC, +2 t-states)
- Panasonic FS-A1GT (MSX turbo R, Yamaha V9958, NTSC, +1 t-state)
- Philips NMS 8245 modded (MSX2, Yamaha V9958, PAL)
- Philips NMS 8250 (MSX2, Yamaha V9938?, PAL)
- Sony HB-75P (MSX1, Texas Instruments TMS9929, PAL)
- Sony HB-F1XD (MSX2, Yamaha V9938, NTSC)
- Victor HC-30 (MSX1, Yamaha YM2220, NTSC)
- Yamaha CX5MII (MSX1, Yamaha V9938, PAL)