This discovery may not seem like much to the world, but it really is a milestone for those that are intimately familiar with hardcore graphics programming of the Commodore 64. The Commodore 64 had numerous glitches and undocumented behavior that made it possible to do seemingly impossible things, such as displaying graphics on parts of the screen where it was not intended to be displayed. In the mid 1980s, a subculture formed with people who wanted to find those tricks and glitches in order to impress each other with stunning displays of hardcore hackery that produced graphical effects that everyone, up to that point, had thought would be impossible.<p>Since all Commodore 64 computers were essentially exact copies of each other in terms of hardware, with (almost) all the same glitches, it was possible to write code that took advantage advantage of them and still worked for everyone. Except for this VSP trick, which annoyingly enough seemed to cause random crashes on a large percentage of machines.<p>This VSP trick made it possible to scroll graphics across the screen in unbelievable speed. If you had ever tried writing a super-optimized machine code routine for scrolling graphics, you'd be absolutely shocked the first time you'd see the speed at which this VSP trick was able to move graphics. And it was extensible in many different ways: it could not only be used to move graphics but also to trick the graphics chip to give more cycles to the CPU, so that you could produce even more stunning and seemingly impossible tricks. So people used VSP, even though it could cause random crashes.<p>But now, finally, we have an explanation for something that has been bugging a small number of hardcore hackers for decades. And the discovery is by itself the same kind of stunning display of hardcore hackery that made the bug so widespread in the first place.
Some background. This is about "demos" and the "demoscene", which are about very, very small programs (e.g. maybe 100 kb at the high end) designed to generate comparatively very sophisticated visual effects, often using many clever tricks and hacks and typically on older hardware (like the commodore 64).<p>For example, here is a video of the "Super Larrson Brothers" demo: <a href="http://www.youtube.com/watch?v=iDMNZa8KjZ4" rel="nofollow">http://www.youtube.com/watch?v=iDMNZa8KjZ4</a> And here is the code itself: <a href="http://www.pouet.net/prod.php?which=51163" rel="nofollow">http://www.pouet.net/prod.php?which=51163</a> it's 170kb and runs on the c64.<p>One technique used in demos is VSP or "Variable Screen Positioning" which allows for displaying a bitmap at an arbitrary horizontal position, with wraparound, it's used by several demos including the one linked above. However, using VSP can sometimes cause a c64 to crash or lock up, and now the cause of that has been found, enabling workarounds which avoid the problem.
For those who don't have a C64 at the ready, here's a video of the demo: <a href="http://www.youtube.com/watch?v=vXcA4OWx0vo" rel="nofollow">http://www.youtube.com/watch?v=vXcA4OWx0vo</a>
If I'm understanding the characterisation of the bug correctly, I think this implies that memory locations ending in 0xff would <i>not</i> suffer from the corruption.
LFT (the author of the demo and the detailed explanation of the bug) has been doing some pretty amazing hardware/software hacking for a really long time. One look at his YouTube channel and it'll be no surprise to you that he came up with this.
<a href="http://www.youtube.com/user/lftkryo" rel="nofollow">http://www.youtube.com/user/lftkryo</a>
I once spent a week tracking down a bug and I felt like popping out the champagne once we got it figured out and fixed!<p>If they had been working on this for 30 years, I could only imagine the joy and exhilaration of squashing this bug...
> The dreaded VSP crash is caused by a metastability condition in the dram.<p>The "dram"? Meaning a unit of volume? : <a href="http://en.wikipedia.org/wiki/Dram_(unit)" rel="nofollow">http://en.wikipedia.org/wiki/Dram_(unit)</a><p>Or did the author mean "DRAM", i.e. dynamic random access memory? Somehow I think the second meaning was intended, in which case, as an acronym, ALL CAPS is required.