Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
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.
2012-01-22 21:10
Skate

Registered: Jul 2003
Posts: 491
That's an interesting subject. What is the main purpose? Is it making a hardware patch? Or creating a test program which can detect problems and prepare the VSP routine according to that machine's bug? I think second one would be awesome but I have a doubt if it is possible or not.
2012-01-22 21:33
iAN CooG

Registered: May 2002
Posts: 3136
If anything, buggy VSPs could be patched knowing that you shouldn't fiddle with d011 at addresses $xxFx by relocating code
Zerox #1
2012-01-22 22:57
Skate

Registered: Jul 2003
Posts: 491
@iAN CooG: yes, but is it always the same addresses in different problematic machines? that's the real question i guess.
2012-01-23 01:16
Krill

Registered: Apr 2002
Posts: 2850
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. :)
2012-01-23 01:47
ChristopherJam

Registered: Aug 2004
Posts: 1380
Intriguing. I have in the past had C64Cs that were very prone to crashing, one to the extent that I nearly despaired of my $d011 scroller being suitable for commercial use. I didn't consider the possibility of it being code-location dependent. If I still had that machine I'd do some tests..
2012-01-23 09:18
S.E.S.

Registered: Apr 2010
Posts: 19
It would be very cool to know the real cause for the crashes. Is it VIC and it's RAM refresh counter running wild? IMHO the ultimate goal is to be able to emulate those crashes in an emulator.

From a coder's point of view, I'd be very glad to know how to avoid those crashes. When creating a new demo part, I always hesitate to use heavy VSP magic because I don't want to leave out too many viewers with real hardware. It would be so cool if there would be some rule of thumb, for example your VSP is safe as long as all writes are from adresses in ranges $xx00 - $xx3F.
2012-01-23 13:02
algorithm

Registered: May 2002
Posts: 702
Very interesting. If this issue with VSP can somewhat be solved it would be great. Zero-X, you had mentioned that placing the code at lower offset stopped the crashes on your machine. Like krill mentioned, it may vary from machine to machine as there does not seem to be any VSP routine in any demo that never crashes. If there is any such demo which uses AGSP/VSP/Linecrunch that does not crash, this would be what to target and analyse
2012-01-23 17:04
Zer0-X

Registered: Aug 2008
Posts: 78
One of the problem is likely that same code doesn't crash on all crash prone machines. So far I only know this piece of code crashes also Jope's machine right away repeatedly.

Maybe the same code crashes on different memory location on other machines. Maybe another kind of code is required. Who knows.

All I've been able to spot from the logic dumps so far is what seems as at some point VIC pulls the BA line low after the first INC, CPU stops after processing the first DEC opcode three times (is that correct behaviour, just fetching the opcode 3x without the address bytes?), after VIC releases the BA line CPU continues executing the loop, but when it fetches the second INC from the memory the low address byte has been trashed, and when it gets to fetch the JMP, also that opcode has been trashed and BOOM.

Btw I noticed from the included gif and dump that I might've left the AEC probe disconnected as it's seen always as high. In my other dumps it's behaving as it should.
2012-01-23 19:36
encore

Registered: Aug 2010
Posts: 61
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
2012-01-25 12:37
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...
 
... 98 posts hidden. Click here to view all posts....
 
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
E$G/hOKUtO fOrcE
csabanw
grennouille
Guests online: 181
Top Demos
1 Next Level  (9.8)
2 Mojo  (9.7)
3 Coma Light 13  (9.7)
4 Edge of Disgrace  (9.6)
5 Comaland 100%  (9.6)
6 No Bounds  (9.6)
7 Uncensored  (9.6)
8 Wonderland XIV  (9.6)
9 Memento Mori  (9.6)
10 Bromance  (9.5)
Top onefile Demos
1 It's More Fun to Com..  (9.7)
2 Party Elk 2  (9.7)
3 Cubic Dream  (9.6)
4 Copper Booze  (9.5)
5 TRSAC, Gabber & Pebe..  (9.5)
6 Rainbow Connection  (9.5)
7 Wafer Demo  (9.5)
8 Dawnfall V1.1  (9.5)
9 Quadrants  (9.5)
10 Daah, Those Acid Pil..  (9.5)
Top Groups
1 Nostalgia  (9.3)
2 Oxyron  (9.3)
3 Booze Design  (9.3)
4 Censor Design  (9.3)
5 Crest  (9.3)
Top Organizers
1 Burglar  (9.9)
2 Sixx  (9.8)
3 hedning  (9.7)
4 Irata  (9.7)
5 MWS  (9.6)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.042 sec.