|
| |
Released At :
Datastorm 2013
Achievements :
C64 Demo Competition at Datastorm 2013 : #7
Credits :
SIDs used in this release :
Scrolltext and other text in this release : ()
Download :
Look for downloads on external sites:
Pokefinder.org
User Comment
Submitted by plagueis on 16 April 2016
| Ultra interesting and informative. This is why I still come here and check in! |
User Comment
Submitted by hedning on 2 February 2016
| Bob: The best thing still is to find a VSP-safe C64, and run on that. Both my compo machines for Gubbdata (6581 and 8580) are 100% VSP safe. |
User Comment
Submitted by Bob on 2 February 2016
I haven't followed the threads lately but is there a hw fix for this?
becoz coding with sw restriction is not really practical, eventhough LFT showed us that it is doable, which in self is an amazing achievement to code with such restrictions. Great Job indeed, hope to see more from you LFT... |
User Comment
Submitted by Photon on 31 December 2015
| Excellent! Greetings to ZrX and LFT :) |
User Comment
Submitted by Ben on 19 August 2013
| Discovering VSP was brilliant. Making it robust possibly even more. Chapeau. |
User Comment
Submitted by Jak T Rip on 5 July 2013
| Respect to the mights VSP tamer! Yepp, if we knew this before we might have worked this in to Jim Slim! |
User Comment
Submitted by hevosenliha on 5 April 2013
Wonderful!
However the graphics are flickering quite a lot on my veeeeery crash prone c128, but at least this doesn't crash!
I'm very interested i a hardware fix... |
User Comment
Submitted by cbmeeks on 29 March 2013
Wow. This is amazing. Too bad I can't run it on my NTSC C64. I have a PAL C64 but no PAL TV. lol
Anyway, is the code to this available? |
User Comment
Submitted by RaveGuru on 15 February 2013
Bowing in awe and respect, sir.
|
User Comment
Submitted by Martin Piper on 12 February 2013
10/10 for the technical work to understand the VSP bug.
I expect some of the emulator writers will add this corruption as a configuration option. |
User Comment
Submitted by Count Zero on 11 February 2013
Awesome explanation and work done here!
While working on Jim Slim I had crashing problems on my old c64 board just like I had on one of the Creatures games and this finally gives a solution to fixers (and partially crackers) having access to real oldschool hardware suffering such symptoms.
While I imagine there can be a hardware fix for crash prone machines I doubt many will apply it just like few actually add a "digi fix" to their machines in reality.
As there is a proven way to avoid or at least reduce vsp crashes now, there might evolve some fixes now, but I seriously doubt it. Unfortunately there are too few people interested in fixing the issue and too few use cases to invest work into. :(
Still - awesome explanation and POC!
|
User Comment
Submitted by Yogibear on 11 February 2013
User Comment
Submitted by Viscid on 11 February 2013
| Thanks Deekay, that clears my confusion. I just thought I missed something the last 25 Years... ;) |
User Comment
Submitted by DeeKay on 11 February 2013
| Viscid: Nopes, it's not just you, of all the 64s I've had not a single one didn't like VSP! ;-) I did see one or two on parties though, crashing happily away when a VSP part would show up in some demo!... |
User Comment
Submitted by Clarence on 11 February 2013
This problem was something I have never expected to be sorted out. And finally we have a solution and a thorough explanation.
Very cool, you made it, deepest respect!
Funny, in the 90's I only had vsp crashing c64's (thus then never coded any vsp), but since I gathered only stable machines, so now it is hard to find a machine to put this demo to a 'real' test. |
User Comment
Submitted by Viscid on 11 February 2013
| I was curious why everyone immediately voted this intro up to 10/10. So, thanks for posting the scrolltext (which I didn't read in the originalintro). Is it just on me or has no one else a C64 which never crashd on VSP-Scrolling? At least not knowing of it ;) |
User Comment
Submitted by Cruzer on 11 February 2013
| Awesome reverse engineering, hacking and explanation! |
User Comment
Submitted by The Phantom on 11 February 2013
Nice explanation to something that has plagued me for some years. Will implement at a later time.
Awesome to explain this, and show it. I'm assuming the 2 vsp logo's were drawn as 1? Even so, looks good, smooth and fluid.
Nice work! |
User Comment
Submitted by algorithm on 11 February 2013
Very nice.
Solution would then be to have same bytes in $x7 and xF Nops (or skip byte before these locations) Even though code would not be optimised as much anymore, it may outweigh the cost of scrolling the bitmap in software (although 1/8th of the visible gfx and music data would need to be replaced every frame or so) |
User Comment
Submitted by MagerValp on 11 February 2013
Here's LFT's full scrolltext, cleaned up for easy reading:
Technical lowdown:
The dreaded VSP crash is caused by a metastability condition in the dram. Some
have speculated that it has to do with refresh cycles, but hopefully the
detailed explanation in this scroller will crush that myth once and for all.
But first, this is what the machine behaves like from a programmer's point of
view. Let us call memory locations ending in 7 or F fragile. Sometimes when
VSP is performed, several fragile memory cells are randomly corrupted
according to the following rule: each bit in a fragile memory cell might be
changed into the corresponding bit of another fragile cell within the same
page.
This specific behaviour can be exploited in several ways: one approach is to
ensure that every fragile byte in a page is identical. If the page contains
code, for instance, corruption is avoided if all the fragile bytes are $ea
(nop). Similarly, in font definitions, the bottom line of each character could
be blank.
Another technique is to simply avoid all fragile memory locations. The
undocumented opcode $80 (nop immediate) can be used to skip them. Data
structures can be designed to have gaps in the critical places.
This latter technique is used in this demo, including the music player of
course. Data that cannot have gaps, i.e. graphics, is continuously restored
from safe copies elsewhere in memory. You can use shift lock to disable this
repair, and eventually you should see garbage accumulating on the screen. And
yet the code will keep running.
Thus, for the first time, the VSP crash has been tamed.
Now for the explanation. The c64 accesses memory twice in every clock cycle.
each memory access begins with the lsb of the address (also known as the row
address) being placed on an internal bus connected to the dram chips. As soon
as the row address is stable, the row address strobe (ras) signal is given.
each dram chip now latches the row address into a register, and this register
controls a multiplexer which connects the selected memory row to a set of
wires called sense lines. Each sense line connects to a single bit of memory.
The sense lines have been precharged to a voltage in between logical zero and
logical one. The charge stored in the memory cell affects the sense line
towards a slightly lower or higher voltage depending on the bit value. A
feedback amplifier senses the voltage difference and exaggerates it, so that
the sense line reaches the proper voltage representing either zero or one.
because the memory cell is connected (through the multiplexer) to the sense
line, the amplified charge will also flow back and refresh the memory cell.
hence, a memory row is refreshed whenever it is opened.
Vsp is achieved by triggering a badline condition during idle mode in the
visible part of a rasterline. When this happens, the vic chip gets confused
about what memory address to access during the half-cycle following the write
to $d011. It sets the internal bus lines to 11111111 in preparation for an
idle fetch, but suddenly changes its mind and tries to read from an address
with an lsb of 00000111.
Now, since electrical lines can't change voltage instantaneously, there is a
brief moment of time when each of the changing bits (bit 3 through 7) is
neither a valid one nor a valid zero. But because the vic chip changes the
address at an abnormal time, there is now a risk that the ras signal, which is
generated independently by another part of the vic chip, is sent while one or
more bus lines is within the undefined voltage range.
When an undefined voltage is latched into a register, the register enters a
metastable state, which means that its output will flicker rapidly between
zero and one several times before settling. This has catastrophic consequences
for a dram: the row multiplexer will connect several different memory rows,
one at a time, to the same sense lines. But as soon as some charge has moved
from a memory cell to the sense line, the amplifier will pull it all the way
to a one or a zero. If, at this point, another memory row is connected, then
the charge will travel from the sense line into this other memory cell. In
short, one memory cell gets refreshed with the bit value of a different memory
cell.
Note that because the bus lines change from $ff to $07, only memory rows with
an address ending in three ones are at risk of being opened simultaneously.
this explains why corruption can only occur in memory locations ending in 7 or
F.
Finally, this phenomenon hinges on the exact timing of the ras signal at the
nanosecond level, and on many machines the critical situation simply doesn't
occur. The timing (and thus the probability of a crash) depends on factors
such as temperature, vic revision, parasitic capacitance and resistance of the
traces on the motherboard, power supply ripple and interference with other
parts of the machine such as the phase of the colour carrier with respect to
the dotclock. The latter is assigned randomly at power-on, by the way, which
could be the reason why a power-cycle sometimes helps.
This is LFT signing off. |
User Comment
Submitted by Oswald on 11 February 2013
| fantastic stuff, the solution is not usable at most VSPs but that's not LFT's fault :) |
User Comment
Submitted by JackAsser on 11 February 2013
User Comment
Submitted by Mr. SID on 11 February 2013
| Revolutionary! But I hope this is not the end of people trying to find a hardware fix. I doubt it will be possible to patch all existing VSP-stuff with these limitations. |
User Comment
Submitted by Burglar on 11 February 2013
excellent proof of concept!
so the job for the coders is clear, avoid all $xxx7 and $xxxf addresses ;))
that's actually pretty damn hard lol ;)
I would say skip the copying back of gfx to fix vsp bugs, as long as it doesn't crash or fuck up the music its ok in my book.
It might be a bit usable that way... I dunno ;) |
User Comment
Submitted by DeeKay on 10 February 2013
Amazing! LFT did it! The everlasting mystery has finally be fully deciphered! Now we just need a hw fix so we don't have to re-code all the demos that use VSP! ;-D
As for this software fix: It's a great feat, but is it really feasible in everyday demomaking use? I mean - Most of the routines using VSP will use bitmap - so they'll need this constant fixing like in this demonstration. And I would assume it takes a significant amount of rastertime to copy the corrupt bytes over *and* you need to have the gfx stored twice in memory! Does not sound like a solution democoders will like, when memory and rastertime are always used for something else!
Edit: Oh, and VIC is right, the cogwheels getting spun by both logos are an awesome finishing touch! ;-D |
User Comment
Submitted by Killsquad on 10 February 2013
| If this is correct and it is the key to crash-free vsp's then this is seriously a 10'er ! Most of the electro jargon went straight over my head, but I get the coding aspect of this. Fantastic job. |
User Comment
Submitted by spider-j on 10 February 2013
User Comment
Submitted by Frantic on 10 February 2013
| If true, then historical! |
User Comment
Submitted by VIC on 10 February 2013
| Nice touch with the cogwheeels ;) |
User Comment
Submitted by Testa on 10 February 2013
This is so damm cool, you solved a c64 mystery.. a straight 10 from me... congratulations!!
|
User Comment
Submitted by Mixer on 10 February 2013
First cars only moved forward. The factory had no reverse engineers.
The forum thread and all the little details revealed one by one has been inspiring to follow.
|
User Comment
Submitted by Shadow on 10 February 2013
Now this is some real, hardcore technical work done here!
It works exactly as advertised as well, runs flawlessly on my VSP-crashing C64, and now with shift-lock pressed, I can see the graphics starting to get corrupted, but since the code is still VSP-safe, it continues running.
Massive props to lft for finally putting this issue to rest!
|
User Comment
Submitted by Skate on 10 February 2013
| this is the way to release a technicial article. :) i hope this is the final solution with no exceptions. thumbs up! |
User Comment
Submitted by tlr on 10 February 2013
Assuming it really works: _Awesome_!
Can anyone with a crash prone machine try to disprove it working?
I do have a very crash prone 6569R1 machine but it's currently packed away.
|
|
|
|
 | Search CSDb |
|
| Navigate | |
|
| Detailed Info | |
|
| Fun Stuff | |
· Goofs
· Hidden Parts
· Trivia
|
|
| Forum | |
|
| Info on other sites | |
|
| Support CSDb | |
|
 |  |
|
9.1/10 (50 votes) 