graphics movement($d011) crashes
Christian Sohler
The problem is, on some (especially newer) c64 the routine does not work.
Sometimes is happenes, that the whole system crashes after a few seconds,
sometimes after a minute (very strange).
What happened ?
Some bytes (those ending with 7 and f mainly) have been changed.
My question:
Why does this routine work on some c64 while it crashes on others ?
(Maybe because of different rams ?)
Ivan
: On the c64 you can move 16-colour graphics by using $d011.
Called by demo-coders "VSP."
: The problem is, on some (especially newer) c64 the routine does not work.
: Sometimes is happenes, that the whole system crashes after a few seconds,
: sometimes after a minute (very strange).
: What happened ?
: Some bytes (those ending with 7 and f mainly) have been changed.
: My question:
: Why does this routine work on some c64 while it crashes on others ?
: (Maybe because of different rams ?)
I've noticed this as well - except not *all* the routines crash, just
some. I've picked up info that when doing a VSP, the DMA occurs at the
"wrong" time (which is why the screen is moved over) and there are some
problems with the current data the 6510 is processing. Perhaps on newer
64's with slightly different circuitry this causes bytes in memory to be
changed (which will eventually crash the routine)... Hopefully someone
more hard-ware oriented can shed some more light on this, and if it's
possilble to avoid.
--
Firefoot/Style
fire...@netaxs.com
215/579-0336
"Where's my Tractor?"
Psycloid
(Christian Sohler) writes:
This is a new problem to me. Does it crash on several computers
(while working reliably on others), or does it crash on only one
you've tried? If it's just one, you've probably got a bad VIC chip.
If it's more than one, try this:
write a program that does absolutely nothing except update location
$D011. There's an off chance that another line in the program which
is executed at the same time you update this location is causeing the
bug. If it still crashes, give some details on what you did. I know
several people that would be interested in this kind of bug.
Psycloid
writes:
>I've noticed this as well - except not *all* the routines crash,
just
>some. I've picked up info that when doing a VSP, the DMA occurs at
the
>"wrong" time (which is why the screen is moved over) and there are
some
>problems with the current data the 6510 is processing. Perhaps on
newer
>64's with slightly different circuitry this causes bytes in memory
to be
>changed (which will eventually crash the routine)... Hopefully
someone
>more hard-ware oriented can shed some more light on this, and if
it's
>possilble to avoid.
Oops, didn't realize someone had already sent a response. You know,
this would explain a problem that a freind of mine had. He used a
highly graphics entensive program for years. The 6510 got fried and
he had it replaced. The computer then worked fine, except now his
favorite program no longer worked. He had to keep switching the 6510
until one worked with the program. He told me it was because the
program probably used some of the undocumented op-codes whiched
changed with new versions of the CPU. Mabey theres a slight timing
problem with newer 6510's.
Andreas Boose
>I've noticed this as well - except not *all* the routines crash, just
>some. I've picked up info that when doing a VSP, the DMA occurs at the
>"wrong" time (which is why the screen is moved over) and there are some
>problems with the current data the 6510 is processing. Perhaps on newer
>64's with slightly different circuitry this causes bytes in memory to be
>changed (which will eventually crash the routine)... Hopefully someone
>more hard-ware oriented can shed some more light on this, and if it's
>possilble to avoid.
My 6569R1 has this behavior when I mess with the hires bit (bit #5 of
$d011). The VIC-II makes a DMA without pulling BA to ground, this causes
some weird results, because the bus is used by the 6510 and the 6569 at the
same time...
sei
l01 lda $dc04
and #$20
eor $d011
sta $d011
jmp l01
l02 inc $d020
jmp l02
Executing this program on my C64 with 6569R1 will corrupt the RAM and
sometimes it even gets out of the first loop into the second - but without
changing the program.
MfG Andreas
Borge Noest
>My 6569R1 has this behavior when I mess with the hires bit (bit #5 of
>$d011). The VIC-II makes a DMA without pulling BA to ground, this causes
>some weird results, because the bus is used by the 6510 and the 6569 at the
>same time...
Sounds like the infamous Magnetic Scrolls bug.
I have it on my machine (The Pawn crashing after a while).
Switching from standard powerup screen mode to lowres bitmap in a loop will
crash the machine in a hurry.
>MfG Andreas
--
|/// bor...@stud.cs.uit.no (Børge Nøst) | Amiga 4000/040 \\\|
|// Box 218, 9001 Tromsoe, Norway | Remember to :-) when needed \\|
|/ The worlds northernmost university | Life is worth living. \|
#Disclaimer: This university does not speak for me.
Andreas Boose
>Sounds like the infamous Magnetic Scrolls bug.
>I have it on my machine (The Pawn crashing after a while).
>Switching from standard powerup screen mode to lowres bitmap in a loop will
>crash the machine in a hurry.
This is the reason why some games crash on some C64.
Different illegal opcodes in NMOS65xx are not the reason, because there are
not different illegal opcodes, it is always the same core in all 65xx
processors.
MfG Andreas
Nicolai Thilo
of 'fooling around' with those 8 bits. It seems that you can do many
different tricks by changing the values at certain X and Y positions
of the raster:
FLD (Flexible Line Distance)
VSP (Variable Screen Positioning(?))
FLI (making '8th lines' on every scanline, allowing the screen memory
location to be changed on every scanline).
Various ways of removing the '8th line', still allowing sprites to be
displayed (thus always used in sideborder opening routines (except
'screen-expansion')).
Memory blanking/corrupting.
...and of course, all the regular stuff like removing the upper and
lower borders... :-)
Eventually, these 'errors' are not similar in every 64, but mostly
are the same in all the old versions (the brown bread boxes :).
IMHO, the errors in the VIC chip and the 'inventions' was what made
the demos so interesting.
I seem to recall that it was impossible to combine FLD and VSP on
an SX64 (it would screw up memory and crash, at least when running
"Double Density" by Mr Cursor), but all other 64 models would do it.
Also, samples didn't sound good on the new white model, since C=
decided to repair whatever caused the click when you changed the
value of $D418.
Zenox/Starion (non-active).
__
/\/./.