| |
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....
|
| |
Poison
Registered: Oct 2004
Posts: 7 |
Light color, slim case, 8580 (C64E, ser.no.: HB4 045509E, made in China)... no crash. (done using a modified AT-PSU) |
| |
Poison
Registered: Oct 2004
Posts: 7 |
Light color, slim case, 8580 (C64E, ser.no.: HB4 1499711E, made in Hong Kong)... dentest crashed 2 times, dentest3 didn't (done using a modified AT-PSU) |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting PoisonLight color, slim case, 8580 (C64E, ser.no.: HB4 1499711E, made in Hong Kong)... dentest crashed 2 times, dentest3 didn't (done using a modified AT-PSU)
Meh, how annoying. I appreciate that you tested and reported it, though!
It is still possible that the timing difference ensures that only one of the methods (DEN or YSCROLL) can crash on a given machine. For approximately how long did you run dentest3? |
| |
Poison
Registered: Oct 2004
Posts: 7 |
Quote: Quoting PoisonLight color, slim case, 8580 (C64E, ser.no.: HB4 1499711E, made in Hong Kong)... dentest crashed 2 times, dentest3 didn't (done using a modified AT-PSU)
Meh, how annoying. I appreciate that you tested and reported it, though!
It is still possible that the timing difference ensures that only one of the methods (DEN or YSCROLL) can crash on a given machine. For approximately how long did you run dentest3?
10-15 minutes each. Should I redo the test with this machine? |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting Poison10-15 minutes each. Should I redo the test with this machine?
Yes please. Especially dentest3.prg, to find out if it's possible that both methods can crash on the same machine. If not, then future demos could have an option for which VSP method to use.
It would be really nice to also get a signal trace from that machine, to see how the phi clock, RAS, BA and the address lines change when VSP is triggered using each of the two methods. But I don't suppose you have such equipment..? |
| |
Poison
Registered: Oct 2004
Posts: 7 |
Same machine, 2 times 30min test (dentest / dentest3), no crash... |
| |
soci
Registered: Sep 2003
Posts: 479 |
C128DCR crashed here with the dentest method after some time (1 hour?). Corrupted addresses seem to be xx97.
A bit disappointing, I still had some hope even if Poison told it crashed for him.
I've spent quite some time moving up 6 pixels a heavy irq/nmi based multiplexing code with sprites moving over the VSP area on open top/bottom borders just to make sure that the VSP can be triggered at line $30 with $10 toggling.
Now I know I don't have to figure out the remaining bugs and can go back to the previous working version ;)
Any more ideas how to get a stable VSP? I also have my soldering iron ready ;)
|
| |
Kabuto
Account closed
Registered: Sep 2004
Posts: 58 |
Now that lft spent some effort working around every 8th byte being prone to corruption let's continue the discussion, maybe things can be improved further :-)
1. The idle byte just before the "VSP bug" is a usual idle byte on all C64s while my C128DCR fetches a different byte (likely line 7 of the @) but besides that runs stable as well. So the C64s are too slow and the C128DCR is too fast to trigger the bug. Could there be a kind of "sweet spot" in terms of production dates?
2. Linecrunching 3 rasterlines before VSP and using bitmap mode during VSP should use low byte $C7 instead of $07. Less bytes to get corrupted but also a bit less usable screen height and (relevant for pure VSP) sprite bug occurring earlier.
3. Does the memory corruption have any predictable pattern? I.e. when 2 columns get mingled what's the outcome depending on the input? Is it predictable (i.e. always ANDed or ORed)? (In this case one could set up 2 test tables, one containing $FF / $00 for even / odd bit weight (= number of set bits within the low address byte) and the other one being inverted and do a quick test to determine which columns were actually corrupted). Or is the outcome at least the same for both mingled columns? (Edit: just 1 or 4 bits might get corrupted at once so watch out when testing that) |
| |
Burglar
Registered: Dec 2004
Posts: 1085 |
I think you should start a new thread with "VSP crash (solved)" or something ;)
discussing ways to simplify and improve on lft's fab work should be interesting! |
| |
lft
Registered: Jul 2007
Posts: 369 |
Quoting Kabuto2. Linecrunching 3 rasterlines before VSP and using bitmap mode during VSP should use low byte $C7 instead of $07. Less bytes to get corrupted but also a bit less usable screen height and (relevant for pure VSP) sprite bug occurring earlier.
I actually tried that, but when I finally got hold of a crash-prone machine that effect crashed instantly. I conclude that for some reason the bus lines do not change to the expected display-mode lsb, at least not immediately.
However, it appears that my demo doesn't crash (trigger the cross-refresh behaviour) on some machines that usually crash on VSP effects. This suggests that it is possible, somehow, to affect either the lsb or the timing from software. Probably the latter. If it turns out to be possible to adjust the timing, I don't think we will find a setting that is safe on all machines, though. But there is certainly more to find out.
What is the sprite bug you refer to? |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
