|
Post by jday6809 on Sept 30, 2022 10:42:48 GMT -5
Okay, so... decided to clean up some code, replacing stuff like:
LDA #0 STA Current_Item
with
CLR Current_Item
Surprisingly (to me), this small change broke my game. Does CLR a variable not do the same thing as assign #0 to a variable?
Thanks in advance
|
|
|
Post by Peer on Sept 30, 2022 11:27:34 GMT -5
That depends. Does the code immediately following the instructions rely on register A being zero? Which is true in the first case, but not necessarily in the second.
|
|
|
Post by D-Type on Sept 30, 2022 11:32:15 GMT -5
Maybe the status register is being set differently?
Can you achieve the same thing with an AND or OR or EOR?
(I'm no expert.)
|
|
|
Post by Peer on Sept 30, 2022 12:01:27 GMT -5
And what exactly is meant by breaking the game? Immediate crash? Vectors looking different? Alternate behavior?
|
|
|
Post by jday6809 on Sept 30, 2022 12:13:33 GMT -5
Hey all! Thanks for the quick response and insightful questions! Turns out Cinematronic figured it out exactly... yep... there was a following function that required a #0 in the A register. Since I had only cleared the variable, and not the A register... that function was more than happy to accept whatever garbage was still hanging out in the A register. Thanks for your time everyone.... wish I had spent more time trying to figure it out before hitting up the forum.
|
|
|
Post by VectorX on Sept 30, 2022 13:38:03 GMT -5
^Oh well, as long as it fixed your problem
|
|
|
Post by Malban on Oct 1, 2022 3:17:27 GMT -5
I don't really like the CLR instruction - at least not memory related. The reason is - it has side effects which are not obvious and have gotton me into trouble before.
clra ; 2 cycles sta somewhere ; 4 cycles ; Sum = 6 cylces
andclr somewhere ; 6 cycl
As you can see the "cleaned up" version takes exactly as long as the explicit version. There is no gain using CLR to clear a memory location.
The reason is, that the 6809 "CLR" instruction not only zeroes a memory location, but also READS it first. (has probably to do with some CPU construction magic..., or it does internally an "EOR" ...)
"CLR somewhere"
actually does:
READ somewhere WRITE 0 to somewhere
If you do not have a register to spare the "CLR somewhere" is ok to use.
My personal problems with the CLR instruction come from the combination with the VIA chip - the VIA in some registers also reacts to READs.
Example:
The SHIFT register of VIA contains #%1111 0000. You just used that to draw a dashed line, the blank register is off, since the last shifted bit was a ZERO.
If you do a: clr VIA_SHIFT
Then VIA immediately starts shifting (which is amongst others triggered by a read) - it shifts out one (or even two?) of the "ONE"s - which results in a dot to be drawn. AFTER that the value 0 reaches the shift register and ~BLANK goes 0 again.
But you have a strange random dot somewhere on your screen....
Ahhh... to much information I guess ;-)
Cheers Malban
|
|
|
Post by jday6809 on Oct 5, 2022 9:32:57 GMT -5
Hey, not too much info at all! That's great to know about clr having to read before writing to memory. I was replacing all my previous LDA #0 STA somewhere commands with CLR somewhere in an attempt to make my file size smaller. But so often I just lda #0 followed by STA somewhere1 STA somewhere2 STA somewhere3...so sounds like that would be faster in the long run (2+4+4+4 cycles) with minimal increase in file size.
It's never too much information for me.... my problem in life right now is only having small 15-minute windows of personal free time to research/develop.
|
|