- 92comments
- 16comments
- 53comments
- 161comments
- 34comments
- 597comments
- 141comments
- 1comments
- 16comments
- 238comments
- 87comments
- 171comments
- 74comments
- 9comments
- 235comments
- 7comments
- 42comments
- —discuss
- 6comments
- 124comments
- 159comments
- 15comments
- 27comments
- 63comments
- 29comments
- —discuss
- 45comments
- 41comments
- 374comments
- 120comments
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!
If they had been working on this for 30 years, I could only imagine the joy and exhilaration of squashing this bug...
What is VSP? Made it very hard to understand what this is talking about.
According to http://en.wikipedia.org/wiki/Commodore_64_demos, VSP is:
"VSP (Variable Screen Positioning), also known as HSP, allows arbitrary x-placement of a bitmap, with the bitmap wrapping around at the border."
That's very nifty, I learned a bit about hardware in there.
C64 modding wikipedia page has more:
http://en.wikipedia.org/wiki/Commodore_64_demos
It appears that it is possible to quickly shift the starting memory location of the buffer that contains the video memory, which means the rasteriser shifts everything around. This allows smooth horizontal/vertical scrolling - the program only needs to write the changed column/row instead of the entire screen.
http://www.lemon64.com/forum/viewtopic.php?t=42580&sid=c...
VSP or 'screen offset' is a technique that allows all kinds of scrolling tricks. If you offset by a single byte you get a horizontal scroll (combine with horizontal retrace timing trickery to get smooth scrolling), offset by a whole scanline and you scroll vertically, offset by a character box height*line width and you get jump character scroll, all without moving a single byte of memory, just write a few hardware registers.
Of course that only works when the screen is not divided up into windows. Tricks like these allowed many of the scrolling games on 80 bitters, and are why you could have smooth scrolled text on a 1 MHz cpu with very little software overhead. Even in the PC era these tricks were commonplace on character generator screen modes for lightning fast scrolling. Bitmapped windows are super CPU intensive if you don't have a graphic card that can move around chunks of memory quickly.
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).
For example, here is a video of the "Super Larrson Brothers" demo: http://www.youtube.com/watch?v=iDMNZa8KjZ4 And here is the code itself: http://www.pouet.net/prod.php?which=51163 it's 170kb and runs on the c64.
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.
The size limitation is actually just one category of demoscene productions, the so called "intros", which come in 4k, 40k or 64kb variety. Demos on newer platforms can be more than 10mb in size.
The size limitation on C64 comes naturally as the disks are only able to store 170kb per side.
Actually, the main event at demoscene parties have traditionally been the demo compo where the typical size limit is something like max 64 MB nowadays.
Other common events are 4k and 64k intro compos.
Here's a good example of a larger demo (Lifeforce by ASD): https://www.youtube.com/watch?v=o9GLl6kI4hQ
For those who don't have a C64 at the ready, here's a video of the demo: http://www.youtube.com/watch?v=vXcA4OWx0vo
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.
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.
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.
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.
The Ataris had this capability before the Commodores, without the crashing. They were designed to scroll entire screens of material almost effortlessly from the beginning. When you combined it with the redefinable (and color) character sets, you could put a scrolling map of Europe in a few K of memory.
Ataris had coprocessors for 256-color graphics, sound, I/O, and intelligent peripherals. You could mix text and graphics modes on the screen line by line. They had hardware sprites. The 800 (and its successors) even had an S-video output. All in 1978.
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. http://www.youtube.com/user/lftkryo
If I'm understanding the characterisation of the bug correctly, I think this implies that memory locations ending in 0xff would not suffer from the corruption.
The "dram"? Meaning a unit of volume? : http://en.wikipedia.org/wiki/Dram_(unit)
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.
That seems to be the fault of the transcription, i.e. by whoever sat and read through the scroll text in order to enter it as a forum comment.
The scroll itself in the intro is in all-caps, i.e. all the text is shown as caps.
Also, I really think context makes it fantastically clear here that it's talking about aspects of computer hardware.
The author had two choices -- fix the problem at the source, or downvote the well-intentioned correcting post. I see which he chose.