VSP-Fix

Preface

This is a very technical article. The findings are partly other people's work, especially Linus "LFT" Åkesson's work, but I also have to give credit to Tommi Lempinen, who has picked my brain so often for explanations that I finally decided to look into the matter and think of a fix. Such a fix would not work nicely as a customer-installable product, so the idea was shelved for some time. With the creation of a new C64 motherboard, I dug out the idea again and implemented it. (Jens Schönfeld)

What's VSP anyway?

VSP stands for "variable screen positioning". The VSP effect (also known as DMA delay, which is technically more correct) allows moving the C64 screen sideways by almost any number of pixels, without the need to move large amounts of data around in memory. While this is a very simple thing on today's computers or on an Amiga, this is nothing that the creators of the VIC-II chip ever intended. The effect is achieved by a write access to $d011, and that's also when things may go wrong on the C64's D-Ram bus. The effect was discovered by accident in the heyday of the C64 by a demo coder and first appeared in the demo VSP&IK+. Since then it was a common effect in the demo scene, but due to the problematic issues with memory corruption was only rarely used in commercial programs (games) - some popular examples are "Another World" and "Mayhem in Monsterland".

what's going wrong

In the half-cycle that follows the write access to $d011, the video chip may or may not (depending on chip revision and circuit board capacitance) change the address on the multiplexed D-Ram address bus from %1111111 to %00000111. If this transition happens close to the falling edge of the RAS signal, then up to two timing specifications of the RAM chips may be violated: The setup time and/or the hold time of the addresses before/after the falling edge of the RAS signal. This has the catastrophic result that data from one row may be stored in the read amplifiers of the RAM chips, but upon closing the row (with the rising edge of the RAS signal) this data will be written back into the wrong row of the chip.

How the fix works

For a hardware fix, all you need is an 8-bit transparent latch that will be inserted just before the address lines are fed into the RAM chips. The latch will be set to "transparent" almost all the time, but set to "store/hold" around the time of the falling edge of the RAS signal. Since this is always happening at the same time within a 1MHz half-cycle, a simple counter that is syncronized with the RAS signal does the job.

The solution on the C64 Reloaded makes use of the colour clock, which is assumed to be fully synced to the 1MHz clock and the RAS signal. The GAL chip needs to know if it's running in PAL or NTSC mode, because the phase relations are different for both modes. Therefore, the colour clock is not fed directly into pin 1 of the GAL chip, but into a different input pin. One output macrocell is connected to pin 1 of the GAL, so the clock can be inverted, depending on PAL or NTSC operation.

The counter will also wrap around at a different position, as PAL operates at 17,7344MHz and NTSC operates at 14,31818MHz.

schematics and source

;PALASM Design Description

;---------------------------------- Declaration Segment ------------
TITLE    C64 Reloaded VSP fix
PATTERN  (none)
REVISION V1.0
AUTHOR   Jens Schoenfeld
COMPANY  individual Computers GmbH, www.icomp.de
DATE     04/11/2015

CHIP  _c64r  PALCE16V8
; although the source is open, you are not allowed to take any
; commercial advantage from this. For licensing, contact iComp.
;---------------------------------- PIN Declarations ---------------
PIN  1          CLK       
PIN  2          cck_in
PIN  3          RAS
PIN  4          NTSC
PIN  12         clk_out
PIN  13         RASdel
PIN  14         C0
PIN  15         C1
PIN  16         C2
PIN  17         C3
PIN  18         C4 ;not used.
PIN  19         VSP

;----------------------------------- Boolean Equation Segment ------
EQUATIONS
clk_out=cck_in*/NTSC
       +/cck_in*NTSC
RASdel:=RAS
/C0:=C0
  + /RAS * RASdel
/C1:=C1*C0
  +  /C1*/C0
  + /RAS * RASdel
/C2:=C2*C1*C0
  +/C2 * /C0
  +/C2 * /C1
  + /RAS * RASdel
/C3:=C3*C2*C1*C0
  + /C3 * /C0
  + /C3 * /C1
  + /C3 * /C2
  + /RAS * RASdel
/VSP=C3*/NTSC
   + /C0* C1*C2*NTSC

;----------------------------------- Simulation Segment ------------
SIMULATION

;-------------------------------------------------------------------

Links

• VSP&IK+ by Meanteam - First known program that exploits "VSP"
• Safe VSP by LFT - First known program that will run although the memory corruption happens.
• VSP Lab V1.1 by LFT - This program was written to systematically analyze the problem, and it can be used to verify if a particular C-64 is affected.
• The VIC Article by Christian Bauer has a technical description of the effect
• In the VICE test programs repository you can find some simple implementations.