| |
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.
|
|
... 100 posts hidden. Click here to view all posts....
|
| |
Burglar
Registered: Dec 2004
Posts: 1089 |
Research must continue of course, but wouldn't it be nice to create more safe vsp code. I mean, as far as we know lft's method works, but it's quite complicated.
Take the double screen compo for example, wouldn't it be cool if we could supply source code of a safe vsp displayer. Hopefully it would also help to get more testers. |
| |
Zer0-X
Account closed
Registered: Aug 2008
Posts: 78 |
Theorize this.
Shhit... Fixed the labeling of 7486 (was erraneously 7408). |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
Quote:wouldn't it be cool if we could supply source code of a safe vsp displayer.
you should try coming up with one... personally i doubt its worth the effort, since you will have to restore the broken graphics all the time, you will certainly see just that. so instead of crashing it would look buggy. i'd just grab another c64 from the pile... :) |
| |
Fungus
Registered: Sep 2002
Posts: 680 |
According to lemming adding buffers to the multiplexers will fix the issue on a breadbox too (he's already done it). Jbevren had the exact same idea after I showed him this schematic yesterday. Preventing VIC from writing to memory at all is the obvious solution then. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
Quote:Preventing VIC from writing to memory at all is the obvious solution then.
and the ram refresh? :) |
| |
tlr
Registered: Sep 2003
Posts: 1787 |
Quote: Quote:Preventing VIC from writing to memory at all is the obvious solution then.
and the ram refresh? :)
You only need to access each row (RAS) of the memory to make it refresh. No need to write. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11359 |
mmhyes, ok, true =) |
| |
lft
Registered: Jul 2007
Posts: 369 |
I don't know what you're talking about. VIC never writes to RAM. The bit bleeding happens when it tries to open several rows almost at the same time, as I've described previously.
As for latching the bus lines, it's certainly worth a try. But until we have empirical data that supports this method, I'm wary that the unstable bus lines might trigger metastability in the latch chip, causing it to produce unstable output, and we're back to square one. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 - Next |
