| |
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....
|
| |
encore
Registered: Aug 2010
Posts: 67 |
How about asking Bil Herd? After seeing a couple of his videos, I could imagine that he would have an idea or two.
http://c128.com/forums/general-discussion |
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Has anyone tried running a problematic C64 using batteries or some kind of filtered PSU? Or even on 5V only (if possible, can't remember which parts require 9V to work)? After reading about the various issues Jens of Individual Computers faced with his ACA1230 accelerator due to noisy PSUs, it would be a good idea to ensure it's not related to the PSU in any way... |
| |
Skate
Registered: Jul 2003
Posts: 494 |
@AmiDog: I'd had two c64s but only one PSU back in the days. One of them had VSP problems but other one was completely fine. Maybe other one had the same problem but with different memory addresses (like discussed above), I'm not sure. But same PSU worked fine with one of the machines. I'm sure many c64 users have experienced the same thing. Just my 2 cents. |
| |
WVL
Registered: Mar 2002
Posts: 895 |
Quote: I just checked two programs which came off the top of my head when i thought of VSP crash-prone: The side-scrolling levels in the classic game Creatures and the two-VSP bitmap scroller on the 2nd side of Xenon's Arcanum.
Creatures has the two VSP write accesses to $d011 at $23b1, and the Arcanum part has them at $2750 and $2d51.
Apparently it's not only $xxfx which is prone to crashes, but maybe there is some kind of logic, as Skate suggested.
Maybe it's a question of how many bits are set in certain ranges of the opcode's address, such that e.g. in zero-page would be quite safe and at $fffx the opposite, while the crash probability distribution in between them is somewhat different from machine to machine, similar to SID filter curves.
But maybe there are also more variables in the equation than just the opcode's address and the particular machine.
I congratulate ZeroX for this discovery though, it's another stepping stone on solving one of the last mysteries of the C-64. :)
I think that mostly has to do with there being 3 VSP's in that part with the scrollers. One VSP to scroll the top part, another to stabilize the screen again and a third to scroll the bottom.
If you disable one of the VSP's (or two), then suddenly it doesnt crash that often anymore. I think it's still a totally weird phenomenon.
Changing VIC's, memory and PSU did not help anything at all during my tests.
The pattern is always the same, the code crashes because memory gets destroyed. You will see destroyed bits in different at the same offset yy (differing all the times) at a lot banks xx $xxyy.
An idea I had was to write some test code in a ROM, so the code would _never_ mess up! That way you could analyse a lot better what happens to the RAM, by simply looking at the screen (bitmap mode or something) to see what gets destroyed and when it gets destroyed.
I think nowadays it would be pretty easy to write a small 8KB testprogram for a cartridge and emulate that cart in 1541u or easyflash or something :) |
| |
enigma
Registered: Feb 2002
Posts: 15 |
That code from ROM idea is quite nice, you may find some pattern in the memory corruption.
On the other hand the first step would be to find out where the incorrect write to RAM appears.
So either a regular write to RAM is seen with a wrong address or it has something to do with refresh.
So with the logic analyzers logs it should be possible to find a RAM read that delivers a wrong value. Even if the CPU does not crash you can compare to a table of expected RAM values.
From this point one could go backward and find f.e. the last refresh to this page and take a look at the time difference (which should not exceed 3.66 ms I think).
I am not sure if the logic analyzer can detect if some signal timing gets corrupted, such as that a signal is not active for 500 ms but just 10 ms f.e.
If it is a regular RAM write the next step would be to identify the source.
Another cause might be that the switching between CPU and VIC as bus master collides if one chip shifts timing by a few ms. Sounds unlikely but as this crash appears just on some C64s and is more or less random gives the whole thing a kind of analog touch...
|
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
have you considerated some radio frequency interferences?
I remember that an old etacs standard cell phone caused many crash problems to me in the past...
Just try to turn off all phones and other rf sources (wireless routers, headphones, and so on)... |
| |
S.E.S.
Registered: Apr 2010
Posts: 19 |
@WVL: That sounds promising! I really wish someone would investigate further on this topic. He has to get his hands on a VSP-crashing C64, though. |
| |
algorithm
Registered: May 2002
Posts: 705 |
I had stated this it many posts previously, but when i actually had a real c64, changing the power supply to a new one removed all crashes completely. I know this may differ from c64 to c64, but just a note |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
I now have two working C64C setups, identical board revisions, running from the same C128 PSU. I'm using the same VIC-II and 8701 clock generator on both of them. One machine keeps crashing, the other one does not. I should try socketing each and every chip on both boards and then do so swapping around to see if that would give any better results.
|
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
Some more testing...
Jope checked his C64C that crashes with this inc/dec $d011 loop and it had the same motherboard revision 250469 with the same gluelogic MOS 251715-01 and same NEC memorychips, tho different speed.
I also repaired one of the C128s from my junkpile and it also seems to be very touchy with that bit of code, trashing the same $xxf7/ff bytes, BUT I can't get it to crash with any of the demos...
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
