> I would like to understand this revised routine a little better, so I have
> a couple of questions (particularly directed at Andrew, but open as always
> to the list):
>
> - Why is it not necessary to include a clc before each adc statement? I
If you already KNOW the carry is clear, all a clc would do is clear it AGAIN
:)
So what I'm saying is try and work out if the carry is in a known state
before you do each of your adc or sbc statements. There are many cases
where it IS in a known state. Even if it's in the WRONG state, you can
compensate for that by adding one less or subtracting one less.
> got into trouble with a very early version of the program by not doing
this.
> - What is the purpose of the adc #0 statement?
If you're adding 16-bit values, you add the low bytes first, then the high
bytes. If the low-bytes overflow, the carry is set. And then you add the
high bytes using that carry flag, which will add +1 to them if there was an
overflow in the low bytes. If you're only adding an 8-bit value to a 16-bit
value, you need to do adc #0 to the high-byte to cater for that possible
overflow. Another way of doing it it branching if the carry is clear (after
the add for the low bytes) and incrementing the high byte if set. In the
particular code example, I noted that the adc #0 wasn't necessary if the
table was guaranteed to be on a single page. In that case, the carry could
never be set after the first low-byte additon, and so there would be no need
to adjust the high byte of the address :) That's what I was doing;
analysing the state of the carry and optimising based on what it
could/should be.
Cheers
A
-
Andrew Davie, TwoHeaded Software
adavie@xxxxxxxxxxxxx
-
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
