| |
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? |
|
| |
HCL
Registered: Feb 2003
Posts: 717 |
I'd say the older the better, but still that's no guarantee. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: 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?
Can I have your C64? Me and my boss Mogwai are currently investigating this so I need a crash-prone C64. |
| |
ready.
Registered: Feb 2003
Posts: 441 |
sometimes certain C64 behave strangely. I remeber a C64-c being able to run all demos I tried (quite many), without crashing, but crashing on Bomberman game for I don't know what reason. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11139 |
Quote:
Can I have your C64? Me and my boss Mogwai are currently investigating this so I need a crash-prone C64.
peter wendrich (the guy behind fpga64) is looking for such a c64 too ... :)
and yeah, this is one of the few unsolved mysteries...you cant really say what kind of c64s have this problem and which dont, there seems to be no relation to the board revision, or vic, or whatever. |
| |
Devia
Registered: Oct 2004
Posts: 401 |
are there any demos that are sure to trigger this bug on the machines prone to it?
|
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
So it is a bit of a gamble, all right, guess I will have to roll the dice and buy one (or two...) C64s and see what happens.
I would really like to help in solving this issue by donating a machine with the problem, however my C64C has too much sentimental value, I will keep that machine with me forever!
But if I buy another machine and it turns out to have the bug as well, I will donate that to suffer some crazy Frankenstein-like experiments at the hands of Mogwai! :)
I will try to find a couple demo that produces the lockups, but as I said I think it is just about any hardware scrolling demo, they usually run for about two to ten seconds before hardlocking. |
| |
JackAsser
Registered: Jun 2002
Posts: 1990 |
Quote: So it is a bit of a gamble, all right, guess I will have to roll the dice and buy one (or two...) C64s and see what happens.
I would really like to help in solving this issue by donating a machine with the problem, however my C64C has too much sentimental value, I will keep that machine with me forever!
But if I buy another machine and it turns out to have the bug as well, I will donate that to suffer some crazy Frankenstein-like experiments at the hands of Mogwai! :)
I will try to find a couple demo that produces the lockups, but as I said I think it is just about any hardware scrolling demo, they usually run for about two to ten seconds before hardlocking.
Maybe we can use it to measure on, I mean... we're all Lunders so... =) U'll get it back. And we won't destroy it, remeber Mogwai is TEH Data doctor. :D |
| |
Clarence
Registered: Mar 2004
Posts: 119 |
c128dcr (metal case) is stable against HW scroll. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11139 |
you cant really say that for sure either :) |
| |
Danzig
Registered: Jun 2002
Posts: 429 |
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. |
| |
Oswald
Registered: Apr 2002
Posts: 5025 |
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: 5025 |
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: 1990 |
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: 11139 |
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? |
| |
chatGPZ
Registered: Dec 2001
Posts: 11139 |
you can check for this bug much more easily... clear the whole memory (use some $a5 pattern or so, not just zeros) then execute inc $d011; jmp *-3 ... the c64 will crash very quickly, or atleast show random bytes in memory after a while. |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Quote: 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. ;)
I can confirm that refreshing the memory by executing a full page of code does not help, I tried it so it's bogus. I also dont think it's a memory-refresh thing.
Another reason why I think this : I swapped the memory for a crash-prone c64 with the memory of a non-crash prone c64. They still behaved the same. Then, I also swapped the VICS! They still behaved the same!!! :P |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
Never seen the problem on any of my old breadboxes, so I would say go for one of those. That way you'll also get a proper SID.
|
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:That way you'll also get a proper SID. what is a "proper" Sid ? if its the one which is closer to the original specs then it must be the 8580;) |
| |
Fungus
Registered: Sep 2002
Posts: 626 |
WVL: That is weird, I had a pal c64 (breadbox) that crashed constantly with anything using agsp/vsp and even fli. I had a few spare vics of different revisions, and I swapped in a r7 or r8 (don't remember now) and the problem completely disappeared.
I had various NTSC machines also crash with vsp, breadboxes, 64-c, 128 and 128DCR.
some worked, and some did not, of ALL of them.
So this being limited to later revision 64's is bs in my opinion cause I had early breadboxes that crashed like hell, and they seemed to be the most prone to it.
Generally I would swap to later vic revisions and these problems would go away.
|
| |
Devia
Registered: Oct 2004
Posts: 401 |
The old R3 VICs tend to run pretty hot, sometimes resulting in really weird bugs. Typically pixel noise to start with and then weird crashes. This is easily proven temperature related by watching the pixel noise disappear the moment you lay a heat sink or even a big fat greasy finger on the poor VIC.
Later revisions (still 6569) are a lot cooler.
This AGSP memory corruption thing has me confused... It doesn't appear to be single bit errors, but rather 4 bit single-bit rols, meaning I see MSB of corrupt nibbles being ROL'ed into LSB of same nibble without affecting the middle 2 bits.
Unfortunately I cant seem to find a c64 that's very suceptible to this bug, so it takes forever to hunt the corruptions down.
|
| |
SIDWAVE
Account closed
Registered: Apr 2002
Posts: 2238 |
I've never seen a demo crash on my first C64.
|
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
OK, this is just plain weird. I have tested with "1 Year Totally Stoned", and the AGSP part runs without problem (tested three times, let it run for a minute or so)!
However the vector part that followed messed up two times out of three tests, almost as running the AGSP before it has somehow put the computer in an unstable state... However there is a loading break in between, so that seems unlikely that any memory corruption would carry over. Strangeness...
Oh and Jackasser - had I lived closer to Lund I would totally have brought my machine for some measuring. Perhaps if there is another BFP/LCP nearby sometime...
-edit- OK, now I was able to watch Royal Arte from start to finish without problems as well! I used to get lockups in the DYCP part. Maybe my C64 got the feeling that I was going to replace it and got its act together! :D |
| |
HCL
Registered: Feb 2003
Posts: 717 |
@Shadow: Yeah, i think you're right about the feelings of your c64 ;). But that test you made sort of sums up my view of this problem also. VSP on the top of the screen, like the bitmap mover (AGSP.. hate that abbreviation..) in "1 Year Totally Stoned" is less error prone than VSP somewhere in the middle of the screen, like the vector-part after. Strange but true. |
| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
HCL: Ahh.. The vector part uses VSP as well, didn't realize that. |
| |
Codey
Registered: Oct 2005
Posts: 79 |
Quote: 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.
i had a breadbox 64 that would crash on vsp routines after a period of time.
what exactly is the $d021 bug? |
| |
assiduous
Account closed
Registered: Jun 2007
Posts: 343 |
Quote:what exactly is the $d021 bug? loop lda#$00 sta $d021 jmp loop gives random gray (half)pixels on the 8565 VIC-II chip. |
| |
Danzig
Registered: Jun 2002
Posts: 429 |
Quote: @Shadow: Yeah, i think you're right about the feelings of your c64 ;). But that test you made sort of sums up my view of this problem also. VSP on the top of the screen, like the bitmap mover (AGSP.. hate that abbreviation..) in "1 Year Totally Stoned" is less error prone than VSP somewhere in the middle of the screen, like the vector-part after. Strange but true.
i agree! in an old x-rated intro doom used vsp on the top of the screen to move a little X-R bitmap. that intro worked even on my first c64c that fuxxored usually on any vsp. he also used vsp to compensate it later on the screen but coded "in the same way". whatever that means for the discussion. it might also depend on "the width of the wank", i never spotted fuxxor with accidently happening vsp when doing f.e. fli without stable raster before. that said, the vsp from doom was also only about 10 to 12 chars wide °":) (iirc!)
EDIT: i quicky found it: its in here (the metallica like XR)
Examples 4 AFL
[/url] |
| |
algorithm
Registered: May 2002
Posts: 702 |
Quote: Quote:what exactly is the $d021 bug? loop lda#$00 sta $d021 jmp loop gives random gray (half)pixels on the 8565 VIC-II chip.
Funnily enough this bug sometimes disappears after power off/on on the same machine.
VSP seems to crash more easily when the grey pixels appear. Its not just a $d021 bug, same issue for $d020 with the same color. |
| |
HCL
Registered: Feb 2003
Posts: 717 |
My c128 *always* shows those d020-d021-bugs, but with the VSP-bug it's totally different. I remember i had to heat it up for ~5 minutes before i started to code on my VSP-shit (and that was totally the coolest shit you could code by then), and then i had about 30-45 minutes to work when the VSP-bug didn't appear as frequently. Then it started to ruin the memory, and if i didn't save before that, it was all lost :D. Madness!! Especially during "1 year totally stoned" that was my every day madness.. |
| |
algorithm
Registered: May 2002
Posts: 702 |
Yes VSP was a nightmare. I remember my poor C64 setup. AR cartridge and Tapedeck. Had to turn off and on c64 multiple times and to run a VSP crash tester until the machine did not crash to continue coding something VSP based.
Have mentioned this quite a few times but i had purchased a reject c64 with a new powersupply and using this new powersupply, every single vsp part worked with NO CRASHES on the same c64 that had problems initially with the previous psu.
It certainly must partially be a Power related issue as well although not sure how VSP sometimes worked when cycling power off/on using even the older psu. |
