Thanx for pointing out my errors. I intend to look
into this further.
For some time I've wondered if there were a faster way
to convert binary to ASCII coded hex. I even played
with some BCD numbers before I understood the Decimal
mode. If you can code an algorithm with the lowest
possible cycle count to process in 1-byte chunks,
please do :-)
If you still think its a good idea to code with SED as
the program's default condition, I would like to see a
routine to plot pixels on the high-res screen in
Decimal mode!!! ;-)
--- Spiro Trikaliotis <Trik-news@gmx.de> wrote:
> Hi,
>
> > The routines are not out of context because they
> are
> > not part of a larger program. I typed them in
> exactly
> > as they are presented in the book, except the
> comments
> > are mine. The only command I left out of each code
> > snippet was the BRK at the end of each.
>
> I know, I'm an owner of this book, too. ;-)
>
> > Besides, its ABSURD to assume that SED is the
> default
> > condition for the entire program. NO-ONE programs
> this
> > way. Even Leventhal recommends keeping D clear
> outside
> > of subroutines! For that reason I say its QUITE
> FAIR
> > to include SED and CLD in the cycle count.
>
> I'm not so sure for this. For example, in a program
> dealing with monetary
> values, it might be the "normal" thing to have
> decimal mode. Think: That we
> are not used with the decimal mode not mean that it
> is not reasonable to use
> this. With mainframes (of these times), most of the
> times, you were working
> with the decimal mode.
>
> Processors before the 6502 mostly didn't have a
> decimal flag, they had extra
> commands to do decimal arithmetic, which corrected
> the value afterward the
> calculation. I believe MOS thought that it would be
> very handy to have this
> mode, because you would not always be forced to
> correct the value after it
> is calculated. So, I would say that MOS indeed
> thought it would be a big
> advantage to be able to write most parts of a
> program in decimal mode -
> else, they would not have included this mode, which,
> as for as I know, no
> other processor (except the 65xx series) has!
>
> > Here're two sample routines I cooked up to test
> your
> > second statement:
> [...]
>
> > ; TRY DECIMAL MODE ALGORITHM
> [...]
>
> You know your error?
>
> [...]
> > JSR MAKEDIG ; 6 CYCLES
> > STA $FB ; 3 CYCLES
> > TXA ; 2 CYCLES
> > AND #$0F ; 2 CYCLES
>
> > ; 2 ITERATIONS FOLLOWING CODE
> > MAKEDIG CLC ; 2x2=4 CYCLES
> > ADC #$90 ; 2x2=4 CYCLES
> > ADC #$40 ; 2x2=4 CYCLES
> > CLD ; 2x2=4 CYCLES
> ^^^
> Here, you're leaving decimal mode. In the second
> iteration, you don't have
> it anymore!
>
> > STA $FC ; 3x2=6 CYCLES
> > RTS ; 6x2=12 CYCLES
> > ; 59 CYCLES TOTAL
>
> > Looks like you were correct Spiro!
>
> Not any more with the error!
>
> > Now, I suppose I can further optimise it by
> removing
> > the subroutine calls and using straight-line code:
>
> [...]
>
> > AND #$0F ; *Can this be omitted?
> > CLC ; **IS THIS EVEN NECESSARY?
> > ADC #$90
> > ADC #$40
> > STA $FC
> > CLD
> > ; 36 cycles. BLAZING FAST!
>
> > * I dont' think its really necessary to mask out
> the
> > high nybble here. Since there is no CoMParison to
> do,
> > the extra nybble should just overflow thru the
> Carry
> > and out into the binary ether, right???
>
> I don't think so! The ADC #$90 is for generating an
> additional carry in case
> we have a value from A - F, but not generate in in
> case we have a value from
> 0 to 9. Additionally, both additions want to add
> $90+$40 = $(1)30 to your
> value, so you end up in the range $30-$39 OR
> $41-$45.
>
> Think of the following case:
>
> You have $28 to convert. The first ADC #$90 now
> generates a carry, since
> $28+$90 = $118 (in decimal mode). So, the second ADC
> #$40 generates
> $18+$40+C = $59. Observe that our result is not only
> out of range, even it's
> lowest nibble is not right because the carry was set
> wrong!
>
> > ** I'm pretty damn sure that the first instance of
> ADC
> > #$40 will eat any carry. Thus, C is already clear
> for
> > the low nybble.
>
> NO! If your initial value was in the range 0-9, the
> ADC #$40 will surely
> GENERATE a carry, because the first ADC generated a
> value in the range
> $90-$99. If your initial value was in the range A-F,
> the ADC #$40 will not
> generate a carry, because the first ADC #$90
> generated a value in the range
> $100 to $104.
>
> > ASIDE - I'm inexperienced with 6502 decimal mode
> > operations. I was SHOCKED to discover that in
> decimal
> > mode $0A is treated as 10 'ones' units! :-O
>
> Well, simplified speaking, think of the decimal mode
> as adding another ADD:
> If a nibble of the result from the first ("real")
> addition is in the range
> "A"-"F", then add 6 to that nibble (that goes for
> both nibbles). Because of
> this strategie, the processor cannot determine of on
> $0A, for example, was
> generated by the first ("real") addition, or was
> there as input.
>
> Spiro.
>
> -
> This message was sent through the cbm-hackers
> mailing list.
> To unsubscribe: echo unsubscribe | mail
cbm-hackers-request@dot.tml.hut.fi.
=====
Get a FREE 6Mb webmail box from go6502! - http://www.geocities.com/profdredd
As low as 2.99% Intro APR from NextCard! - http://www.nextcard.com/index6.html?ref=aff0074521
PayPal is the FAST FREE and SECURE way to send money! - https://secure.paypal.x.com/refer/pal=profdredd%40yahoo.com
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
-
This message was sent through the cbm-hackers mailing list.
To unsubscribe: echo unsubscribe | mail cbm-hackers-request@dot.tml.hut.fi.
Archive generated by hypermail 2.1.1.