| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
VSP crash (not solved yet)
I recently found my C64C to be very prone to crash with certain demos and finally managed to create a reproducible crash while banging the $d011 register so I hooked up my logic analyzer and here are some logs of the event taking place.
http://oms.wmhost.com/misc/VSP_Crash_100MHz.zip
A testprogram was looped at address $0ff0. It could've been placed at pretty much any $xxf0 address and it still would crash within few seconds. Running the code at lower offset on the memorypage quite effectively prevented it from crashing on the machine used for testing. A shorter version with only inc/dec/inc/jmp not crossing the page boundary crashes.
The symptoms were always the same; low address byte of the 2nd inc at $xxf7 and/or the opcode of the jmp at $xxff are suddenly trashed. The byte at $xxf7 ends up being 0x00, 0x01, 0x10 or 0x1d. Byte at $xxff ends up being 0x0c, 0x40, 0x48 or 0x4d.
As a post-work the decoupling caps of the memorychips in the C64C used were replaced and a new thick wire delivering power directly to the memorychips was soldered in place. This had no effect and the machine still crashes with this code, as well as with Booze Design demos Royal Arte and Tsunami for example. Powersupply used is a C128 PSU with C64 powercable soldered next to the C128 powercable.
Logfiles VSP Crash 100MHz 3_31.csv/txt have the actual crash event taking place.
|
|
... 98 posts hidden. Click here to view all posts....
|
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
@lft: that won't work, unfortunately.
VSP only works by leaving _idle mode_ in the middle of a line by causing a bad line condition because the VIC doesn't increment its character pointer in idle mode so it ends up having it incremented by less than 40 chars at the end of the line.
It won't work if the line starts non-bad non-idle because also in that mode the character pointer is incremented so by the end of the line the VIC has incremented it by the usual 40 chars.
What your suggestion does: it causes a character row starting at line $31 but without a bad line. So it'll re-use the characters and colors still in its buffers from the last row of the previous frame. Activating a bad line condition in the middle of row $31 now just makes the VIC fetch the remainder of the first row (after 3 "FLI bug" chars of course).
Edit:
It looks like it's impossible to secure VSP. The low address byte of idle fetch is always $FF but the low address byte of a normal fetch won't ever reach that value - unless of course you've used VSP before on the same frame :D |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
This being-inbetween-states thingy kinda reminds me of what Jens and Ninja found out when they investigated the bug that the MMC Replay would not load properly and crash when some sprite (I think it was Sprite 6) was turned on. Maybe they can share what they found out when measuring the address lines on the expansion port? ;-) |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
I looked through everything again. My "impossible" line conclusion from my previous post was wrong, but it still seems to be impossible to fix.
First of all, I guess the VIC is going to fetch from $3807 (and not from $3800) in above dump. That would make sense as the character line is 7 and there's even a $07 flashing briefly.
But the upper 5 bits must all be set to 1 as well for a fix to work.
Character mode won't work - the VIC is doing an idle access that cycle and thus character data is 0, meaning that those 5 bits would be 0 as well.
Bitmap mode won't work either - without VSP the VIC can only do 320-byte increments, meaning that the only values to choose from for this lowmost byte would be $07, $47, $87 and $C7. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting KabutoVSP only works by leaving _idle mode_ in the middle of a line
Doh! You're quite right. Sorry for getting everybody's hopes up.
The dummy address (3800 or maybe 3807 as you point out) doesn't seem to be what VIC would have fetched if this were a normal display line (that would've been too easy). In the captured crash, d018 had not been modified and ECM was active, so VIC would've fetched font bits from 1000-11ff. That's why we need more data, to see if the dummy address is a constant or if it can somehow be manipulated.
But I agree that the least significant bits may reflect the value of RC. If so, this leads us to another workaround, but this is not practical at all: Basically, it would mean that when you perform VSP, all memory locations that end with 7 or f may get trashed. So avoid them! For code, you could use e.g. 2-byte nops to skip them. After doing VSP, you could restore some of these bytes (the interrupt vector at $ffff, for instance). You could store the next part (or loader) split into 7-byte chunks, and use a small 7/f-avoiding routine to unpack them. Very tricky, but that's what we do.
But like I said, this is not practical. Even if you decide to allow graphics to get corrupted as long as the code doesn't crash, you still have to deal with the music routine. With an 8 KB tune, that's 1 KB of potential code you have to restore every frame (and if you use an unrolled loop, that loop would also have to be 7/f-avoiding); but the point of VSP in the first place was to avoid shuffling a lot of data.
We're back to the crossroads of my first post in this thread: Hardware fix (which should be quite easy using a 555 or something: pull down RAS a fixed amount of time after PH0 goes high, then release it immediately when PH0 goes low), and/or figure out if it's possible to change the dummy address. |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting KabutoBitmap mode won't work either - without VSP the VIC can only do 320-byte increments, meaning that the only values to choose from for this lowmost byte would be $07, $47, $87 and $C7.
$c7 would be better than $07. In this case, only memory locations ending in c7, cf, d7, df, e7, ef, f7 and ff would get trashed. Hence, a large chunk of each page would be safe for code.
But this is based on a number of assumptions: That the dummy address contains some bits of VC during bitmap modes, that the row multiplexer only flickers between the rows whose addresses match the pattern on the address bus, and so on. After all, we only have one crash log from one machine. I'm looking forward to a larger data set! |
| |
lft
Registered: Jul 2007
Posts: 369 |
Alas, the address won't end in c7. VC will end in c0, but VC is shifted by three when forming the address. |
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
I disagree. VC address always increments by 40, no matter what gfx mode is used, unless you use VSP. I already accounted for the shift-by-3 in bitmap mode by writing about "320-byte increments". So e.g. after 3 rows VC address is $78, shifting by 3 -> $3C0, adding 7 (for row 7) -> $3C7, taking just the lowmost byte -> $C7.
EDIT: Fun fact: My C128DCR seems to behave differently. It doesn't display the idle byte for the fetch in question, it either fetches another byte (in default charset mode that might be line 7 of char 0 (@) which has byte value 0) or doesn't display anything at all. |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
So is the theory on what's actually happening confirmed now? Cause if it is, we can go the next step and ask ourselves what exactly the hardware difference between the machines suffering from VSP-problems and those that do not is! ;-) AND why some machines only seem to suffer temporarily from it, at least according to folklore i heard ("when it's on for a few minutes the problems go away") |
| |
DeeKay
Registered: Nov 2002
Posts: 362 |
Quote: I disagree. VC address always increments by 40, no matter what gfx mode is used, unless you use VSP. I already accounted for the shift-by-3 in bitmap mode by writing about "320-byte increments". So e.g. after 3 rows VC address is $78, shifting by 3 -> $3C0, adding 7 (for row 7) -> $3C7, taking just the lowmost byte -> $C7.
EDIT: Fun fact: My C128DCR seems to behave differently. It doesn't display the idle byte for the fetch in question, it either fetches another byte (in default charset mode that might be line 7 of char 0 (@) which has byte value 0) or doesn't display anything at all.
Interesting. Cause line 6 of the @ contains the only bit of the ROMchar that is NOT a straight EOR#$FF of the inverted character, as all people who accessed the NUFLI editor hidden part in Leon's picture can confirm! ;-) COINCIDENCE??? |
| |
Skate
Registered: Jul 2003
Posts: 494 |
Don't we have a contact with any ex-Commodore engineers? If i were one of them and someone asked me a question like VSP bug, I'd be interested in finding the cause of the problem. I'm not saying they would be interested or they could help but why not inviting them to this discussion?
Since I don't know any of the ex-Commodore company guys, i just wanted to ask if any of you know them. I believe some of you should have contact addresses from a magazine interview etc. right? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
