[CSDb] - User Forums - VSP crash (not solved yet)

You are not logged in - nap

CSDb User Forums

Forums > CSDb Discussions > VSP crash (not solved yet)

2012-01-22 21:01

Zer0-X

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....

2012-11-09 12:02

AmiDog

Registered: Mar 2003
Posts: 97

Perhaps a stupid question, but as the VSP crashes seems to be RAM related, what would happend if one replaced the DRAM with some SRAM instead (assuming it's technically possible)?

2012-11-09 15:39

Zer0-X

Registered: Aug 2008
Posts: 78

Quote: Perhaps a stupid question, but as the VSP crashes seems to be RAM related, what would happend if one replaced the DRAM with some SRAM instead (assuming it's technically possible)?

Several people have been suggesting already long ago that SRAMs would prevent the crash since they wouldn't suffer from glitches during refresh cycles. It would require some extra logic tho.

Regarding that old VIC running on the new board, it had crashed while running Royal Arte last night. It also has been running Tequila Sunrise for almost 10 hours today without problems. Tho it could all be due to powercycling inbetween as it has an effect to the internal timings of the VIC, more in 8565 than in 6569.

2012-11-11 14:32

Kabuto
Account closed

Registered: Sep 2004
Posts: 58

Idea: the DRAM batch might play a role, too. DRAMs buffer the address applied during RAS resp. CAS internally. Susceptibility for messing up might depend on internal logics of the DRAM in question.

I suppose Commodore put the cheapest RAM they could get, even mixing multiple batches for single units. (I have a C64 which had bad RAM chips - so bad that it booted with ?OUT OF MEMORY ERROR. All 8 RAM chips had the same label, just 4 had a shiny case and 4 had a mat case. 3 of the shiny ones were clearly defective so I replaced all 4.)

So there should be a lot of different RAM batches in all the C64s that were ever built. Unfortunately RAMs aren't socketed and thus require desoldering for replacement. But it might be worth a try on a machine that crashes.

Would it be worth collecting info about C64s (such as RAM labels) that do crash to track down the problem? What do you think?

2012-11-11 21:37

lft

Registered: Jul 2007
Posts: 369

All right folks. Zer0-X and I stumbled over something interesting.

Remember that the VSP crash is caused by a metastability hazard, whereby VIC changes its mind about what address to read at the exact moment when the row address is latched into the DRAM chips. (This hazard leads to a crash with some probability, and the probability seems to be different depending on machine, temperature, phase of moon and so on.)

We have discovered that, at least for some machines, the timing is different depending on how you trigger the VSP effect. As mentioned in the VIC article, VSP (DMA delay) can be triggered in two different ways on rasterline $30: Either by changing YSCROLL to 0 or by changing the DEN bit to 1. It would appear that VIC changes its mind about the address slightly later if you use the DEN method -- and by that time, the row address has already been latched safely.

This seems too simple to be true, so we need independent verification. We are asking you to test the attached program on your crash prone machines, and see if it crashes. We would also like you to test it on your stable machines, to see if the changed timing perhaps causes crashes where there previously weren't any. (If so, this could be tested at runtime and the VSP code modified accordingly.)

Here is the program: http://www.linusakesson.net/files/dentest.prg

I would also like to thank SounDemoN for helping us out with additional testing.

2012-11-11 23:02

Stone

Registered: Oct 2006
Posts: 168

Extremely interesting thread! I just thought I'd add some of my own experience on the subject and let you guys decide its relevance. I have an old breadbin (early eighties) that has excibited a degradation in stability, not only with vsp, but also other $d011 related splits. The timeline of when the crashes started occuring goes something like this: (late 80s) VSP -> Illegal modes (bitmap+egbm) -> bitmap+fld -> simple bitmap splits (90s). How accurate this timeline is, I don't really know..

With my extremely limited knowledge of electronics, this would suggest to me that the degradation I have seen is caused by leaky capacitors and that there at least can be a hardware solution to this (as already suggested).

2012-11-11 23:21

Kabuto
Account closed

Registered: Sep 2004
Posts: 58

@Stein: Did you try using a different power supply? Or measuring the supply voltage at the VIC while the machine is running? (Depending on your knowledge of electronics you might have someone else do that for you so you don't accidentally short circuit anything)

@lft: This would indeed fix the problem but if I didn't get anything wrong there's a disadvantage: it reduces usable screen resolution for combined VSP+linecrunch (to scroll the bitmap wherever you want) in most cases.

When doing linecrunch first it can start right at row $30 (for 25 lines), be directly followed by VSP, and directly after the VSP row it's possible to cause a bad line for image display.

However, the DEN method forces one to use VSP first. The VSP line is always followed by 8 non-idle displayed raster lines (except for C128 where it's possible to use $D030 to work around) but linecrunch only works for lines that would normally be idle. Thus you'd have the VSP line, then 8 wasted lines, then 24 or 25 linecrunch lines.

2012-11-11 23:35

encore

Registered: Aug 2010
Posts: 61

lft: For what it's worth, my VSP-stable Hong Kong manufactured C64C (with old SID) has been running dentest.prg for more than 1 hour without any problems.

2012-11-11 23:52

Kabuto
Account closed

Registered: Sep 2004
Posts: 58

@lft: Your code changes $D011 from $08 to $18. Did you try changing the line as well (e.g. changing $D011 from $07 to $18)? I don't think there'll be a large difference but it might affect timing a bit as well.

Or generally: does the actual line change for VSP cause timing differences? I.e. changing $D011 from $18 to $17 resp. $17 to $18? Since it's NMOS it might create a small timing difference, too.

2012-11-12 01:50

Stone

Registered: Oct 2006
Posts: 168

@Kabuto: I never tried it with another powersupply. The old one went up in smoke a couple of years ago, so if I ever get the machine out of the basement again, I'll test it with a new one.

2012-11-12 07:30

lft

Registered: Jul 2007
Posts: 369

Quoting Kabuto

However, the DEN method forces one to use VSP first. The VSP line is always followed by 8 non-idle displayed raster lines (except for C128 where it's possible to use $D030 to work around) but linecrunch only works for lines that would normally be idle. Thus you'd have the VSP line, then 8 wasted lines, then 24 or 25 linecrunch lines.

EDIT: Removed faulty reasoning that was off by a cycle. You were right.

Quoting Kabuto

Or generally: does the actual line change for VSP cause timing differences? I.e. changing $D011 from $18 to $17 resp. $17 to $18? Since it's NMOS it might create a small timing difference, too.

Good idea! We'll have to measure that.