| |
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....
|
| |
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: 11136 |
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: 11136 |
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: 625 |
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.
|
| Previous - 1 | 2 | 3 | 4 - Next |
