[CSDb] - User Forums - New VSP discovery

You are not logged in - nap

CSDb User Forums

Forums > C64 Coding > New VSP discovery

2013-07-19 21:01

lft

Registered: Jul 2007
Posts: 369

New VSP discovery

First off, this is what we already knew: VSP causes the VIC chip to briefly
place a logically undefined value on the DRAM address lines during the
halfcycle following the write to d011. If the undefined value coincides with
the RAS signal, every memory cell with an xxx7 or xxxf address is at risk of
getting corrupted. The relative timing of the undefined value and RAS depends
on several factors including temperature.

We also knew that the undefined value could be delayed slightly if VSP was
triggered by setting the DEN bit instead of modifying YSCROLL. This was enough
to avoid a crash on some machines.

I wanted to investigate whether there were other ways of controlling the timing
of the undefined value. Based on a combination of educated guesswork, luck and
plenty of trial-and-error, I could observe the following: The timing depends on
the specific 3-bit value that is written to YSCROLL, as well as the 3-bit value
that was stored in YSCROLL previously.

This means that we can trigger VSP using one of 56 methods (eight different
YSCROLL values for various rasterlines, seven non-matching YSCROLL values to
switch from), each with slightly different timing.

Using the techniques from my Safe VSP demo, I created a tool that would trigger
VSP many times, check if memory got corrupted, and keep track of the number of
crashes caused by each of the 56 methods. I then looked for a pattern in these
statistics.

Intriguingly, if I arranged the 56 crash counters in a grid with the vertical
axis corresponding to the rasterline and the horizontal axis corresponding to
the exclusive-or between the rasterline and the dummy value that was stored in
d011 prior to the VSP, then the crashes would tend to occur only in a subset of
the columns. When my crash prone c64 is powered on, the VIC chip is cold, and
there are no crashes. Within a minute, crashes start to appear in column 7
(meaning that all three bits of YSCROLL were flipped). As the chip heats up,
more crashes begin to appear in columns 3, 5 and 6 (two bits flipped). After
several more minutes, crashes show up also in columns 1, 2 and finally 4 (a
single bit flipped), but by this time, there are no longer any crashes in
columns 5, 6 or 7. Finally, when the VIC chip has reached a stable working
temperature, my machine no longer crashes.

This is what it might look like four minutes after power-on:

Now, let me stress that I only have one VSP-crashing c64, and these results
might not carry over to other machines. I hope they do, though. I would very
much like you (yes, you!) to run VSP Lab (described below) on your crash prone
machines and report what happens.

Is this useful? Short answer: Yes, very. But it hinges on whether the behaviour
of my c64 is typical. Even without the mentioned regularity in the columns, it
would be possible to find a few safe combinations for a given machine and a
given temperature. But the regularity makes it so much more practical and also
easier to explain to all C64 users, not just coders.

Let's refer to the seven columns as "VSP channels". For a given machine at a
given temperature, some of these channels are safe, and possibly some of them
are unsafe. It takes about 5-10 minutes for the VIC chip to reach its working
temperature. If you know that e.g. VSP channel #5 is safe on your machine, and
you can somehow tell a demo or game to use that specific channel, then VSP
won't crash.

My measurement tool evolved into a program called VSP Lab, depicted above,
which you can use to find out which VSP channels are safe to use on your
machine. It triggers a lot of VSP operations and visualises the crashes in a
grid, where each column corresponds to a VSP channel. Remember that a cold and
a hot VIC behave differently, so don't trust the measurements until about ten
minutes after power-on. You can reset the grid highlights using F1 to see if
channels which were unsafe before have become safe.

Demos and games could prompt the user for a VSP channel to use, or try to
determine it automatically using the same technique that VSP Lab is based on.

From a coding point of view, all you then have to do in order to implement
crash-free VSP, is to prepare the value X that you'll write to d011 to trigger
VSP, and the value Y which is X ^ vsp_channel. Then, on the rasterline where
you want to do VSP, you just wait until the time is right and do:

        sty $d011
        stx $d011

On the VSP Lab disk image, there's a small demo effect that you can run. It
will ask you for a VSP channel to use, and if you give it a safe number, it
should not crash.

This technique is so simple and non-intrusive that it's quite feasible to patch
existing games and demos, VSP-fixing them.

Also, this discovery explains the old wisdom that if you attempt VSP more than
once per frame, the routine will be more likely to crash. Here's why: In a demo
effect, you typically perform VSP on a fixed rasterline, so the value you write
to d011 will be constant. It is reasonable to assume that the old value of
YSCROLL will also be constant. Therefore, a given VSP effect will consistently
end up in the same VSP channel. On a machine with N safe VSP channels, the
probability of survival is therefore p = N / 7. If you do VSP on two different
rasterlines, each VSP will likewise end up in a channel, but not necessarily
the same one. The probability that both end up in a safe channel is p*p. If we
assume that most crash prone machines have at least one safe channel, we have
0 < p < 1 and therefore p*p < p. Q.E.D. To verify this, I patched vice to
report the channel every time VSP was performed. Sure enough, VSP&IK+
consistently uses VSP channel 1, as does Royal Arte. Krestage 3 uses VSP
channel 2. The intro of Tequila Sunrise, which performs VSP twice per frame,
uses VSP channels 1 and 3, and so does Safe VSP.

Finally, I will attempt to explain the observed behaviour at the electronical
level. Suppose each bit of YSCROLL is continually compared to the corresponding
bit in the Y raster counter, using XOR gates. The outputs of the XOR gates are
routed to a triple-input NOR gate, the output of which is therefore high if and
only if the three bits match. A triple-input NOR gate in NMOS would consist of
a pull-up resistor and three pull-down transistors. But the output of the NOR
gate is not a perfect boolean signal, because the transistors are not ideal.
When they are closed, they act like small-valued resistors, pulling the output
towards -- but not all the way down to -- ground potential. When YSCROLL
differs from the raster position by three bits, all three transistors
contribute, and the output reaches a low voltage. When the difference is two
bits, only two transistors pull, so the output voltage is slightly higher. For
a one-bit difference, the voltage is even higher (but still a logic zero, of
course). When we trigger VSP, all transistors stop pulling the voltage down,
and because of the resistor, the output voltage will begin to rise. But the
time it needs in order to rise to a logic one depends on the voltage at which
it begins. Thus, the more bits that change in YSCROLL, the longer it takes
until the match signal is asserted.

I have a fair amount of confidence in this theory, but need more data to
confirm it. And, once again, this is only of practical use if the average crash
prone machine has safe channels, like mine does. So please check your
equipment! I'm looking forward to your reports.

2013-07-19 22:25

Perplex

Registered: Feb 2009
Posts: 255

Very interesting!

I've run VSP Lab on my C64C for about 50 minutes now, and my results are pretty much exactly as you describe them on your machine: no crashes during the first few minutes, then crashes starts in channel 7, then channel 3, 5 and 6, and finally in channel 1, 2 and 4 after about 17 minutes. At 20 minutes, I cleared the highlights, and now another 30 minutes after that I only have new crashes in channels 1, 2 and 4.

I don't know if it has any significance, but in the last 30 minutes, channel 1 only has crashes in line 6, and no channels have crashes in line 4.

2013-07-19 23:42

Shadow
Account closed

Registered: Apr 2002
Posts: 355

First of all, thanks to lft for continuing to investigate the VSP issue - this is some very interesting finds.

I have run the VSP-Lab on my crash-prone C64 and here are the results.

I started with a cold, machine and for the first 5 minutes or so, I had no crashes at all.
Here's a the status after 16 minutes running:

I now assumed "working temperature" was reached, and did a reset of highlights/time and let it run for another 16 minutes (32 total):

So on my machine it seems like the singe-bit-channels (1,2,4) are safe somehow. I'll run more tests tomorrow and see if this still holds true.

Anyway, I tried running the demo after that, choose channel 1 and it ran without a hitch!

Once again, fantastic job lft!

2013-07-20 09:36

Shadow
Account closed

Registered: Apr 2002
Posts: 355

Well, scratch that single-bit-channels are safe on my machine! :(
Running a new test now, and after 30 minutes I have crashes on all channels. Will let it run for a while more and then do a clear highlights and see if it has stabilized to ONLY crash on the single-bit channels (as both lft and perplex machines seem to do).

2013-07-20 09:52

Perplex

Registered: Feb 2009
Posts: 255

Update: after running for about an hour and a half, I reset the highlights and timer, then let it run for another hour or so, and there were NO crashes at all! It looks like my C64C is indeed VSP-safe when properly warmed up. I will now turn it on and let it stay at the basic prompt for 90 minutes before starting VSP Lab, and report here what happens then.

2013-07-20 10:06

hedning

Registered: Mar 2009
Posts: 4732

My c64c (The gubbdata compo machine) was turned on by this experiment, and just as the rest of you, it had no crashed the first 5 minutes or so. After some chaotic 25 minutes it looks like this:

After that I resetted time and cleared the highlights and run for another 25 minutes:

For a long time it looked like channel 1 and 2 were safe, but after 15 minutes (40 minutes totally) they also got their amount of crashes. After 25 minutes (50 totally) it looks like channel 4 (0 crashes since startup) and 7 (safe after warmup) are the safe ones on my machine, but I'll let it run for some hours today, and then unleash VSP Lab again...

(EDIT) The demo did crash directly on channel 7, though, but not on channel 4) (/EDIT)

2013-07-20 11:02

Shadow
Account closed

Registered: Apr 2002
Posts: 355

OK, here are my latest results:

Power on the machine, no crashes in the first minutes.
Then after 35 minutes, we have this

I let it run for a bit more (maybe an hour) then powercycled, and ran another 16 minutes

So my machine seems to have this behavior:

From first powerup (when cold) - stable for a few minutes.
The during warmup (from 5 up to 60 minutes or so) crashes on first multi-bit channels, then more towards single-bit channels.
Fully warmed up (60 minutes +) occasional crashes on single-bit channels.

2013-07-20 12:25

hedning

Registered: Mar 2009
Posts: 4732

2 hours of LFT demo on channel 4 without crash (Gubbdata compo machine). Time to see how the report looks like after a 3h warmup, resetted and ran VSP Lab for 5 minutes, and wtf? Channel 4 is screwed after just one minute? Does it matter if the computer is resetted? Maybe I should restart the computer completely instead with the power switch? Did that. No errors at all for 20 minutes.

Is this interesting? Should it matter if you restart your computer or just reset it? Ergo: It seems that after being restarted completely in a warm up state my computer shows no errors at all (tried the demo, and there it died on channel 1 and 2 at least). When resetted channel 4 (that worked flawlessly for over 2 h before, running the demo) and some other channels were showing errors after just some minutes.

The most disturbing thing is that the demo still crashes even if the VSP Lab tells me there should be no crashes. And yes, lft, you may borrow this machine (and many more - I guess at least 10) for testing purposes. :)

2013-07-20 13:58

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

Does it matter if the computer is resetted?

the timing/behaviour changes randomly at either reset or powercycle - making testing pretty much a gamble :)

and yes, interesting program!

2013-07-20 15:28

hedning

Registered: Mar 2009
Posts: 4732

Quote:

the timing/behaviour changes randomly at either reset or powercycle

Randomly? I left the computer on for 1,5h now, and got these results:

After that I reset and tried the VSP Lab three times in a row, and got similar patterns:

After that I made a powercycle, and got these results:

Resetting your machine gives not very random results at all. In this very case I got channel 3, 5, 6, and 7 without crashes four times in a row.

Making a powercycle seems to make pretty random patterns, though. For every powercycle it seems that a new pattern comes up, a pattern that will survive a reset, but not a powercycle. This needs more testing of course. Maybe it's just my machine.

2013-07-20 15:51

chatGPZ

Registered: Dec 2001
Posts: 11386

Quote:

Resetting your machine gives not very random results at all.

you cant prove that with a handful tests, really. make a couple of thousends of them, then come back :) if your results "prove" anything, its that powercycle and reset do different things. if it all.

... 43 posts hidden. Click here to view all posts....

Previous - 1 | 2 | 3 | 4 | 5 | 6 - Next

Refresh

Subscribe to this thread: