| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
How to find a C64 capable of HW-scroll?
I have had my C64-C for more than 20 years, and I love the thing.
However, it always, ALWAYS locks up on hardware scrolling effects (VSP/AGSP or whatever it is called).
That meant that I could never watch for exaple the Horizon demos with large x/y scrolling pictures back in the day.
Then there was the 'pc-style' period from 1994 and the rest of the nineties where demos wasn't using such tricks much more, and all was good.
Lately though I have seen more and more demos use the hardware scrolling tricks again, which means lockups for me and not being able to watch the demo.
The fact that I am pissed of that people use code that is not compatible with all C64s will probably not make much difference, so I guess I am forced to track down another C64, but how do I make sure that it can cope with hardware scrolling?
I think it is a question the average eBay seller is unable to answer, but maybe there is something I should look for? Are old breadbox ones generally better? |
|
... 26 posts hidden. Click here to view all posts....
|
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
it works on my c128dcr too (get one if you can, awe beast), it can also handle loaders of which others used to complain :) and my old breadbin couldnt take it. |
| |
yago
Registered: May 2002
Posts: 332 |
I only use c64c, and they are "mostly" prone to VSP bug.
Obviously, the bug is triggered by manipulating $d011, causing abnormal badline-behaviour.
Its almost sure that the Bugs manifests by not (enough) refreshing memory, which causes bits or bit patterns to change values.
Afaik, there are currently 2 theories.
Grahams Theory is that some VIC-II (which is responsible for DRAM-Refresh) are sometimes wrongly initialised, and then VSP Bug can occur. This can be tested by having a VSP crashing C64, and switching him on/off, testing a VSP prone Demo, until it does not crash. Then only reset, and Bug should not appear.
Another Theory (sorry, cant remember who came up with it first) claims its a bad combination of PSU (and the Power itself), Memory and Temperature.
This can be tested by getting a good PSU, testing after C64 is off for at least 30 minutes.
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
The $d021 bug on new VICs also only occurs sometimes on some machines. When it occurs, it's "persistent" until power off, regardless of resets. And when it doesn't occur, it doesn't occur until power cycle.
Lotus has a machine that toggles this bug every second time on average. Now, back when we discovered this, we didn't know about the $d011 bug. If this particular c64 is prone to the $d011 bug, and someone could give a demo example which exposes both the $d021 and the $d011 bug it just migt be interresting to see if the two bugs are related.
|
| |
AlexC
Registered: Jan 2008
Posts: 293 |
I would be very careful stating which type / rev of machine is bug free - c64/128 have a lot of strange and unexplained bugs and pushing the machines behind original limits just make them more obvious. Commodore did use different parts during c64/128 manufacture process and we all know that 100% compatibility is basically nonexistent. Add to it age of those machines which is not helping either. I would say that PSU is one reason and this is the poor part of whole design. Also read how 128 has been designed - it's miracle it is not crashing every cpu tick ;) I have different set of incompatibility issues when researching different cartridges. I have AR carts not working on certain models or behaving differently. Can't really explain it either.
So the best way to find one is to test it ;) |
| |
Quetzal
Registered: Jul 2002
Posts: 71 |
Quote: a little raster to test against
(based on my experiences in the early 90ies):
- original breadcase c64 can handle vsp
- c64-c / c64-II can not handle vsp
- aldi breadcase can not handle vsp or anything :D
- standard c128 can not handle vsp
- c128 (not metal) can not handle vsp
but: old vic can and new vic can't seems not
to be the solution. a rather old rumour sez
it depends on the cheaper memorychips used.
However, my standard c128 seems to work just fine. Indeed, I used it when coding some parts that featured vsp scrolling. |
| |
Oswald
Registered: Apr 2002
Posts: 5031 |
Quote:Also read how 128 has been designed - it's miracle it is not crashing every cpu tick ;)
you're underestimating Bil Herd a lot imho. The real miracle is that its 100% compatible despite being a totally new design. (for what I know... except the few extra visible regs, which you cant really help anyway. ;) |
| |
Dizzy Devil
Registered: Feb 2003
Posts: 11 |
I agree with yago, I think that AGSP prevents the RAM refresh on the single line where it's executed, since the cycle range for the video DMA may be moved so far to the right that it overlaps with the refresh cycles. I remember seeing the memory totally messed up after an AGSP part had crashed.
Does this memory corruption always happen? Could someone write an AGSP which does no writes into the memory, except the absolutely necessary ones? What happens if you run an AGSP effect for just a few seconds without the computer crashing - is the memory left fully intact or are there slight changes?
As far as I know, the VIC has a refresh address counter which is normally incremented after each refresh. What happens when a refresh is missed? If it's incremented anyways, this row (column?) would not be refreshed until the next time the counter reaches this value, which may be long enough for some bits to flip. However, if the counter is not incremented, this row/column might simply be refreshed in the next raster line and everything would be fine. Maybe the VIC revisions differ in this aspect.
If that's true, could it be possible to work around this bug by refreshing some memory locations manually? Maybe not, because how would you find out which memory cells are next going to be affected by a missing refresh?
I just wish the designers of the VIC had made the video ram counter accessible as a proper register. Imagine how much more powerful and effectively faster the 64 would have been, at least for games, at virtually no cost.
|
| |
JackAsser
Registered: Jun 2002
Posts: 1995 |
I've spoken to SLC quite much about this and he spoke with the fpga64 guy. It's quite certain it's not a memory refresh cycle being missed. Fact 1) A single missed refresh cycle is not enough to distrupt the memory contents, it's just to quick. Fact 2) Doing a full page read directly after VSP will refresh the memory and should therefore prevent the bug, it doesn't.
The fpga64 guys however found some other very interesting issues when switching from chars to bitmap (commonly done when u VSP actually). Strange power spikes (very short) occurs on the memory line, and perhaps these will destroy the memory contents. What has to be done is to measure RAS and CAS during mode-switch and check if they're the reason for the bug. If this is the reason then a HW-fix must be applied (a simple HF-filter actually on RAS & CAS).
I'll keep u notified once I've persuaded my boss to measure this for me. ;) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11150 |
yes indeed... we met some weeks ago to do some fpga64 testing/tweaking and also talked about that vsp issue... unfortunatly then none of the c64s we had for testing had that problem, bah, typical =) |
| |
Devia
Registered: Oct 2004
Posts: 401 |
Shadow: Does 1 Year Totally Stoned crash on your c64? |
| Previous - 1 | 2 | 3 | 4 - Next |
