#471 VDP access throttling mechanisms not implemented, causing VRAM corrupton on software using 'turbo' with new VDP timing

SD Snatcher

The new VDP I/O timing emulation broke ExperTurbo support, because the /WAIT feature of the V9958 isn't emulated yet.

Solution: Emulate the /WAIT feature of the V9958, which is enabled by the bit2 of the VDP R#25

Tested on openMSX-0.9.1-506-g6cc03ba, on Windows-7.

Steps to reproduce the problem:

1) on MSX-DOS, enable the turbo using TURBO.COM from this link: http://www.amusementfactory.com.br/msx/getfile.php?fn=turbo11.zip

2) Load any MSX2 game. The VRAM will be corrupted. I tested using King Valley2 MSX2 on scc+ (loaded with SCROM.COM)


  • Wouter Vermaelen

    Do you have any more technical information about how the /WAIT pin of the VDP is connected to the rest of the MSX, I assume it's directly or indirectly connected to the
    /WAIT input of the Z80. Is there some 'intelligent' circuit in between to only stall the Z80 on a 2nd VDP I/O request, like in a turboR?

    Also do you happen to know exactly when the VDP asserts the /WAIT output? The V9958 datasheet only has a very brief description of this function. Now that we know the VDP-VRAM access behavior in detail, I can make an educated guess, but only a guess.

  • SD Snatcher

    SD Snatcher - 2013-07-13

    The /WAIT pin on the MSX bus works in a very similar way to the /INT signal: It's a big logic AND between all the built-in devices & slots so any of those can request a WAIT (or a interrupt, in that case) to the CPU.

    This was a feature clearly designed to allow Z80s with more than 5.37MHz (*1) to access the VRAM.

    I did some tests some years ago, but I had no access to a logical analyzer. Those obviously are not very precise tests, but probably results are enough for the educated guess, until someone dissects this better using a logical analyzer.

    The V9958 /WAIT generation indeed seem to be somewhat intelligent. My test set was done connecting a LED to the V9958 /WAIT output pin, and connecting the /WAIT to the CPU. The circuit was designed so that only V9958 /WAIT requests would light up the LED, isolating any /WAIT requests from other devices. My circuit could also disable the M1 waitstate generator for an instant +/-20% speed increase.

    The results were:

    1) If the WTE bit of the R#25 is disabled, no waitstate request is ever generated
    2) I tested with several CPU clocks, to check the limits. When the WTE bit is enabled, those were the results:
    2.1) From 1.78MHz to 5.37MHz no waitstate seems to be generated. Disabling the M1 waitstate at 5.37MHz resulted in the LED lighting up very dimly.
    2.2) At 6MHz, the led started blinking very dim. This means that very few waitstates were being generated. Disabling the M1 waitstate instantly increased the LED brightness a bit.
    2.3) At 7.14MHz the led light strobe seemed to be around 25% of the LED brightness
    2.4) At 10.74MHz the led light strobe seemed to be around 50% of the LED brightness

    From the educated guess side of things, what seemed to happen is that when the Z80 tried some VRAM access before of it's reserved time slot, the V9958 would issue the /WAIT until the access time slot comes.

    As the V9958 datasheet states, no WAITs seem to be generated for accessing the V9958 registers. It only generates WAITs for VRAM access.

    *1: 5.37MHz seems to be the V9958 limit for VRAM access without extra waits. The register access handles 7.14MHz without trouble, and maybe can take even more.

  • Manuel Bilderbeek

    This issue explains (probably) why the patched Gradius 2 (which uses the 5.3 MHz feature) is now broken on the Panasonic MSX2+ machines. It relies on the /WAIT feature.

  • Manuel Bilderbeek

    As a workaround, use the too_fast_vram_access setting on 'ignore. However, see bug #534....

  • Manuel Bilderbeek

    • summary: The new VDP I/O timing emulation broke ExpertTurbo support --> Missing /WAIT feature on V9958 (causing VRAM corrupton on software using 'turbo')
  • Manuel Bilderbeek

    Oh, this isn't the only thing... According to FRS:
    "The Panasonic2+ doesn't have the V9958 /WAIT pin connected.

    Instead its turbo chip does some form of throttle control. It checks the VBLANK/HBLANK states for that."

    And that stuff isn't implemented either, of course. So, there are 2 cases that can cause corruption with the present VDP implementation.

  • Manuel Bilderbeek

    • summary: Missing /WAIT feature on V9958 (causing VRAM corrupton on software using 'turbo') --> VDP access throttling mechanisms not implemented, causing VRAM corrupton on software using 'turbo' with new VDP timing
  • Manuel Bilderbeek

    Some more info from FRS, after I asked him which machines have /WAIT connected:

    AFAIK, of the commercially sold machines only the CIEL ExpertTurbo has this pin connected.

    It's said that the Victor HC-9x(T) has a V9958 and that it has this pin connected, but I never found any proof that such machine even exists, or any confirmation of its real VDP.

    AFAIK, openMSX implements VDP I/O throttle only for the S1990 and non-turbo T9769 machines.

    Turbo MSX machines have the following mechanisms for VDP I/O throttling:

    • Panasonic MSX2+ machine: turbo controller 6140140, which is only partially emulated by openMSX.
    • Victor HC-9x(V) and HC-9x(A): HD64180 builtin I/O waitstate generator
    • Victor HC-9x(T): Said to be the V9958 /WAIT feature. Unconfirmed.
    • CIEL ExpertTurbo: V9958 /WAIT feature.
    • GR8bit: this 14Mhz~20Mhz machine features the SuperTurbo 3.1 controller. It slows down the CPU to 3.57Mhz for a configurable number of cycles (default=256). AFAIK, the /WAIT pin isn't connected. This machine isn't yet emulated by openMSX.
    • Third party turbo expansion kits exists everywhere, but none of them are emulated by openMSX. The majority of them implements the same slowdown mechanism as the SuperTurbo 3.x.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks